SQL Server Log Shipping Kurulumu

Bilindiği üzere MSSQL üzerindeki databaseler için temelde 3 farklı backup yöntemi vardır. Full backup, differansiyel backup ve transaction backup. Full backup database’in tam bir görüntüsünü içerir. Diferansiyel backup ise full backup aldındıktan sonraki değişiklikleri içeren backuptır. Transaction backup ise transactional işlemlerin tutulduğu LDF dosyalarının yedeklenmesidir. Ve full backup sonrasındaki değişikleri ardışık olarak tutarlar. Backup çeşitleri ile alakalı ayrıntılı bir makaleyi yakın zamanda yayınlayacağız, şimdilik bu konuları bildiğinizi farz edip öyle devam edeceğim. Bir beyin fırtınası yapacak olursak A database’inin düzenli olarak tran (transaction) backupları alınıyorsa ve ben bu veritabanının önce full backupını sonrasında ise tran backuplarını başka bir sunucuya restore edersem nihayetinde elimde tran alınma ve karşıya yüklenme süresi kadar geriden gelen bir kopya elde etmiş olmaz mıyım? Logshipping ile yapılan işlem aslında tam olarak da budur. Tran backupları yüklemenenin 3 farklı yöntemi vardır. Tran backuplar RECOVERY, NORECOVERY ve STANDBY modlarda restore edilebilir. RECOVERY: Bu modda restore edilen tran backup […]

SQL Server Log Shipping Kurulumu

Bilindiği üzere MSSQL üzerindeki databaseler için temelde 3 farklı backup yöntemi vardır. Full backup, differansiyel backup ve transaction backup. Full backup database’in tam bir görüntüsünü içerir. Diferansiyel backup ise full backup aldındıktan sonraki değişiklikleri içeren backuptır. Transaction backup ise transactional işlemlerin tutulduğu LDF dosyalarının yedeklenmesidir. Ve full backup sonrasındaki değişikleri ardışık olarak tutarlar. Backup çeşitleri ile alakalı ayrıntılı bir makaleyi yakın zamanda yayınlayacağız, şimdilik bu konuları bildiğinizi farz edip öyle devam edeceğim.

Bir beyin fırtınası yapacak olursak A database’inin düzenli olarak tran (transaction) backupları alınıyorsa ve ben bu veritabanının önce full backupını sonrasında ise tran backuplarını başka bir sunucuya restore edersem nihayetinde elimde tran alınma ve karşıya yüklenme süresi kadar geriden gelen bir kopya elde etmiş olmaz mıyım? Logshipping ile yapılan işlem aslında tam olarak da budur.

Tran backupları yüklemenenin 3 farklı yöntemi vardır. Tran backuplar RECOVERY, NORECOVERY ve STANDBY modlarda restore edilebilir.

RECOVERY: Bu modda restore edilen tran backup sonrasında veri tabanı açılır ve hem okumaya hem yazmaya izin verilir. Ancak veri tabanı açıldığı için bunun üzerine tekrar yeni bir tran backup yüklenemez. Tekrardan Full backup yüklemek ve onun üzerine tekrardan ilgili tarihe kadar olan Tran backupları yüklemek gerekir.

 

NORECOVERY: Bu modda restore edildikten sonra veri tabanı açılmaz. Hem okumaya hemde yazmaya izin verilmez. Ancak elimizde her an açabileceğimiz bir veri tabanı kopyası olmuş olur.

RESTORE DATABASE veritabaniadi WITH RECOVERY

Komutu kullanılarak veri tabanı kolayca açılabilir. Bu modda veritabanı üzerine ardışık olarak tranlardan yükleme yapılmasına izin verir.

STANDBY: Bu modda ise restore edilen veri tabanı yanlızca okunabilir modda açılacaktır. Ayrıca veri tabanı içerisinde herhangi bir transactional işlem yapılamadığı için norecovery modda olduğu gibi üzerine yeni bir tran yüklenebilir.

Logshipping yapılırken bu yukarıda bahsettiğim 3 moddan 2si kullanılabilir. NORECOVERY ve STANDBY.

Öncelikle bu makale için hazırladığım ortamdan bahsedeyim. Makinama 2 adet INSTANCE kurulumu yaptım. SERVER1 ve SERVER2 şeklinde. Microsoft’un örnek veritabanlarından olan AdventureWorks veri tabanını SERVER1 üzerine restore ettim.

Logshipping

Yapılacak işlemler tran backupların alınması ve geri yüklenmesi temelli olduğu için işlemi yapacağımız veri tabanının Full ya da Bulk-Logged modda olması gerekir. Zaten aksi takdirde transaction loğları olmayacaktır. Bunun için öncelikle veri tabanı özellikleri option kısmından veri tabanını Full moda çekiyorum.

Logshipping - Database Properties

Logshippingi kurduğumuzda 4 farklı JOB oluşacak. Bu joblardan biri transaction backupları alacak. Diğeri alınan backup’ı hedef sunucuya kopyalayacak. Bir diğeri hedef sunucuya kopyalanan tran backup’ı restore edecek. Sonuncu job ise monitöring vazifesini gerçekleştirecek.

 

Task-Logshipping

Veritabanına sağ tıklayıp task > ship transaction log tıklıyoruz. Aynı ekrana veri tabanına sağ tıklayıp properties diyerek de ulaşabiliriz.

EnableLogShipping

Ensable diyerek aktif ediyoruz. Backup setting tıklıyoruz ve ayarlamalarımızı yapmaya başlayacağız.

logshipping-transaction-logbackup-settings

Açılan ekranı biraz tanıyalım.

Network path ile başlayan kutucuğa ağ üzerinde her iki sunucunun erişebildiği bir path yazıp bacupları oraya almasını söyleyebilirsiniz. Ya da if the backup folder is located on… şeklinde devam eden kutucuğa local bir path yazabilirsiniz. Ancak kullanacağınız local path’e ikinci sunucunun erişimi olması gerekmektedir.

72 yazan kısım kaç saat sonra (dakika ve gün olarak da ayarlanabilir) alınan backupların silineceğini belirler.

1 yazan kısım ise kaç saat sonra backup alınmazsa alarm üretileceğini belirtir. Şimdilik olduğu gibi bırakıyorum.

Job name oluşturulacak backup jobının ismini belirtir. Schedule kısmı ise bu JOB’ın ne kadar sürede çalıştırılacağını belirtir. Default olarak 15 dkda bir alınacak şekildedir. O şekilde bırakacağım.

logshipping-secondery-database

Backup alınma işini hallettik ve sıra ikinci instance’ımız ayarlamaya geldi. Add kısmından 2. İnstance’ımızı ekleyelim.

logshipping-secondery-database-settings

Initialize Secondery Database kısmında:

Yes generate a full backup seçilirse 1. Sunucudan full backup alıp 2. Sunucuya restore eder.

Yes restore a full backup seçilirse mevcutta alınan bir full backup 2. Sunucuya restore eder.

No, the secondery database… kısmı seçilirse kendimizin manuel olarak bir full backup alıp restore etmemiz gerekir.

logshipping-secondery-database-copy-files

Copy Files sekmesine geçtiğimizde ise 2. Sunucuda bir path girmemiz istenir. Bu path üzerine alınan backuplar kopyalanacaktır.

logshipping-secondery-database-transaction-log-restore

Restore Transaction Log sekmesi bizim en önemli ayarlarımızdan birini ihtiva eder. Logshipping’i okunabilir bir replica için yapacaksak bu kısımda kesinlikle standby mod seçmemiz gerekiyor.

Disconnect users in the database seçeneğini seçersek veri tabanına bağlı bir kullanıcı varsa o kullanıcının bağlantısını koparacaktır.

logshipping-secondery-database-standby

Eğer bir monitöring sunucumuz varsa logshipping işlemlerini o monitöring sunucusu ile izleyebiliriz. Benim şuan böyle bir sunucum yok sadece işlemin nasıl yapılacağını göstermek adına 2. Sunucumu monitöring sunucusu olarak ayarlayacağım.

logshipping-monitor-server

Her şey başarılı ise aşağıdaki görüntüyü göreceksiniz.

logshipping-success

Restore edilen son transaction logları kontrol edebileceğiniz scripte tıklayarak ulaşabilirsiniz.

Benzer Yazılar

SQL SERVER RIGHT-LEFT PARTITION

SQL Server 5 gün önce

SQL Server’da partitioning, büyük veritabanı tablolarını daha yönetilebilir ve performanslı hale getirmek amacıyla kullanılan bir tekniktir. Bu teknik, tablonun verilerini fiziksel olarak değil, mantıksal olarak parçalara ayırır. Veriler, belirli bir partition function ve partition scheme kullanılarak farklı bölümlere yönlendirilir. Partitioning, özellikle büyük veri kümeleriyle çalışan veri tabanlarında sorgu performansını artırır ve veri yönetimini kolaylaştırır. Partition Function ve Partition Scheme nedir? Partition Function: Verilerin hangi kriterlere göre bölüneceğini belirler. Örneğin, bir tarih aralığına göre verileri ayırmak. Partition Scheme: Verilerin hangi filegroup’larda depolanacağını belirler.   Örnek olarak Range LEFT ve Range RIGHT olmak üzere iki ayrı tabloda partition nasıl yapılır sizlere göstereceğim. İlk olarak Range LEFT olan partition yapısından başlayacağım. Öncelikle Veri tabanıma yeni filegroup ve file ekliyorum Şimdi sıra FUNCTION ve SCHEME oluşturmakta ben tablomu yıllık olarak partition yaptım sizler ihtiyaçlarınız doğrultusunda aylık,günlük vs yapabilirsiniz. LEFT partition dediğimiz olay vermiş olduğunuz tarih aralığına eşit bir veri geldiğinde bu veriyi solundaki partition […]

Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

SQL Server 2 hafta önce

İçindekilerVeritabanı Recovery Pending Durumu Nedir?Veritabanı Neden Recover Pending Duruma Düşer?Recovery Pending Durumu Nasıl Çözülür?SonuçKaynaklarVeritabanı Recovery Pending Durumu Nedir? SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme)  moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur; Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi, Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi, Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin  geri alınmasıdır.   Veritabanı Neden Recover Pending Duruma Düşer? SQL Server Restart Süreci SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo işlemleri sürecince devam eder. Ani Sistem […]

SQL Server DMV ve DMF – 6

SQL Server 2 hafta önce

Bu yazımızda DMV ve DMF Serimizin 6.sına devam edeceğiz. Bir önceki seride Memory’ye ilişkin DMV ve DMF’leri ele almıştık. Bu yazıda Memory konusunda devam edeceğiz. SQL server’da Memory kavramı en önemli kavramlardan biridir. Özellikle tüm transaction işlemlerinin önce Buffer sonra disk üzerinden devam ettiğini düşünürsek buffer’ın oynadığı kritik rolü daha iyi anlayabiliriz. Bu yazıda Memory’nin durumunu ve monitör edilmesine bakacağız. Özellikle Performans sorunlarında memory konusunda sorun yaşandığı durumda nasıl okumak gerektiği önemli rol oynamaktadır. Hangi database’de, hangi tablo’da sorun yaşandığına ilişkin bilgilere bu paylaşım sonrasında görebileceğiz. SQL Server’ın Memory kullanım durumunu incelediğimde; select physical_memory_in_use_kb/1048576.0 AS ‘physical_memory_in_use (GB)’, locked_page_allocations_kb/1048576.0 AS ‘locked_page_allocations (GB)’, virtual_address_space_committed_kb/1048576.0 AS ‘virtual_address_space_committed (GB)’, available_commit_limit_kb/1048576.0 AS ‘available_commit_limit (GB)’, page_fault_count as ‘page_fault_count’ from  sys.dm_os_process_memory; Görsel – 1   Physical_memory_in_use: Kullanımda olan Fiziksel Memory miktarını gösterir. locked_page_allocations: Memory’de lock’lanmış olan Page’lerin miktarını belirtir. virtual_address_space_contained: SQL Server VAS(Virtual Adress Space) için ayrılan miktarı belirtir. available_commit_limit: SQL Server tarafından kullanılabilecek Memory Miktarını gösterir. […]

0 Yorum

Yorum Yaz

Rastgele