SQL Server ASP.NET C# Kitabı

SQL Server yüksek eriÅŸilebilirlik çözümlerinden olan Log Shipping modelinde öncelikle aktif (birinci) sunucunun full backup’ı alınıp ikinci sunucuya kopyalanır ardından belirli peryodlarda birinci sunucunun log backup’ı alınıp ikinci sunucuya kopyalanır. Böylece iki sunucununun veri tabanı düzeyinde aynı olması saÄŸlanmış olur. SQL Server 2000 üzerinde log shipping iÅŸlemi için Enterprise Manager’ın Database Maintenance Plan Wizard aracı kullanılır. Bu aracı kullanmadan önce aÅŸağıdaki notları dikkate almamız gerekir.

1 – Ä°lk adım olarak Log shipping modeline dahil edilecek primary server ve secondary server sunucuları tanımlanır. Bu iki sunucu mutlaka iki ayrı fiziksel sunucu olacak diye bir durum yok. Aynı sunucu üzerindeki iki veritabanı arasında da log shipping iÅŸlemi yapılabilir. Ayrıca riski azaltmak amacıyla birden fazla secondary server kurulabilir. Primary database’in full veya bulk-logged recovery modelini kullanması gerekir.

2 – Seçmeli olarak bir monitor server kurulur. Monitor server, primary database üzerinde en son ne zaman transaction log alındığını, secondary server’in en son hangi backup dosyalarını kopyaladığını ve restore ettiÄŸini ve bu süreçteki hataları izler. Monitor sunucunun, primary ve secondary sunucularından ayrı olması tavsiye edilir. Bir monitor sunucusu yapılandırıldıktan sonra log shipping kaldırılmadan bir daha yeniden yapılandırılamaz.

3 – Sunucuların güvenlik ayarının düzenlenmesi. Log shipping iÅŸlemini yaptığımız Windows kullanıcısının tüm sunucularda SQL Server systems administrator (sa) yetkilerine sahip olması gerekir.

4 – Paylaşım klasörlerinin oluÅŸturulması. Primary ve secondary olmak üzere iki dosya paylaşımının yapılmış olması gerekir. Önce birinci sunucu tarafında kaynak veritabanının transaction loglarının tutulacağı bir klasör ardından ikinci sunucu tarafında bu logların taşınacağı ve restore edileceÄŸi bir klasör oluÅŸturulur. Burada dikkat edilmesi gereken konu her ikisi sunucudaki SQL Agent’in kullandığı Windows kullanıcısının bu klasörler üzerinde yetkilerinin olmasıdır.

5 – Ardından bu üç sunucu (primary, secondary ve monitor) Enterprise Manager / Management Studio üzerine register edilir.

Aşağıdaki şekilde log shipping modeli çizilmiştir.

Şimdi bu işlemleri üzerinde adım adım uygulayalım. Kaynak ve hedef olmak üzere iki tane sunucumuz var.
Primary Server -> WXX\KAFKA
Secondary Server -> DW

Birinci sunucu (WXX\KAFKA) üzerinde log backuplarının alınacağı klasörü oluÅŸturalım. ÖrneÄŸin C:\LogShipOrnek\Logs\ olarak oluÅŸturduÄŸumuz klasör için \\WXX\Logs\ ÅŸeklinde eriÅŸebileceÄŸimiz ÅŸekilde bir share folder oluÅŸturalım. Bu klasöre hem birinci hem de ikinci sunucu eriÅŸecek ÅŸekilde yetkilendirme yapalım. Dışarıdan bu klasöre backup dosyaları kopyalanacağı için en iyi çözüm Everyone’a full hak vermektir.

Hem DW hem de WXX\KAFKA sunucusunu Enterprise Manager üzerinde register ettikten sonra “Management » “Database Maintenance Plan” aracığını saÄŸ tıklayarak “New Maintenance Plan” menüsünü tıklayıp sihirbazı baÅŸlatalım. Bilgilendirme ekranını geçtikten sonraki ikinci ekranda hangi veritabanlarının bu modele dahil edilip edilmeyeceÄŸi seçilir. Log shipping iÅŸleminin kullanılması için bu ekrandaki “Ship the transaction logs to other SQL Servers (log shipping).” seçeneÄŸinin seçilmiÅŸ olması lazım.

Bu ekrandan sonraki ekranlarda optimizing data, checking integrity veya performing a full database backup ile ilgili herhangi bir seçenek girmeyip “Specify Transaction Log Backup Disk Directory” ekranına gelinceye kadar tüm ekranları geçelim. Bu ekranda “Use This Directory” seçeneÄŸini iÅŸaretleyip “C:\LogShipOrnek\Logs” klasörünü gösterelim. Aynı zamanda bu ekrandaki “Remove Files Older Than” seçeneÄŸini kullanarak log backupların ne kadar süre arÅŸivde bekleyeceÄŸini de belirleyebiliriz.

Bu ekrandaki ayarlara göre log dosyaları ilgili klasörde Kaynak_tlog_yyyymmddhhmm.trn olarak kayıt edilir. Sonraki ekran olan “Specify the Transaction Log Share” ekranında log backup klasörünün networkten eriÅŸim yolunu yazalım (\\WXX\Logs\ ).

“Specify the Log Shipping Destinations” ekranında Add buttonunu tıklayıp ikinci sunucu veya sunucuları ekleyelim.

Bu ekranda yedek sunucu olarak görev yapacak olan DW sunucusunu ekledik. Ayrıca DW üzerinde veri tabanı ilk defa yaratılacağı için mdf ve ldf dosyalarının hangi klasörde olacağını ve log dosyalarının DW tarafında hangi klasöre kopyalanacağını tanımlıyoruz. Bu ikinci sunucunun nonrecovered durumunda olması gerekir.
no recovery mode – Veritabanına her türlü kullanıcını eriÅŸimini engeller
standby mode – Sadece okunabilir (read-only) eriÅŸimlere izin verir. Ayrıca transaction logların restore edilmesi esnasında baÄŸlı kullanıcıları sonlandırmak için bu ekrandaki “Terminate users in database” seçeneÄŸi kullanılır.

Sunucuyu ekleyip diÄŸer ekrana geçelim;”Initialize the Destination Databases”. Bu ekranda iki sunucuyu eÅŸitlemek için gerekli olan full backup’ın ÅŸimdi mi alınması yoksa daha önce alınıp alınmadığını belirtiyoruz. Kaynaktaki veritabanımız çok büyükse bu iÅŸlemi gece almamız daha uygun olacaktır. Ekranda gösterildiÄŸi gibi full backupın ÅŸimdi alınmasını saÄŸlayıp diÄŸer ekrana geçelim.

Sonraki ekran olan “Log Shipping Schedules” ekranı log shipping iÅŸlemlerinin hangi sürelerde gerçekleÅŸtirileceÄŸi belirtilir.
Copy/Load Frequency, ne sıklıkta backup dosyalarının ikinci sunucuya kopyalanacağı ve restore edileceğini belirtir.
Load Delay, backup copy veya restore jobları arasındaki süreyi belirtir. Bu süreyi azaltmak için deÄŸeri sıfıra yaklaÅŸtırmalıyız. Nitekim bu alanın varsayılan deÄŸeri 0′dır.
The file-retention period, ikinci sunucuda log backupların ne kadar süre tutulacağını belirtir. Varsayılan değerde olduğu gibi son 24 saate ait backupların tutulması tavsiye edilir.

Bir sonraki ekrana geçelim. “Log Shipping Thresholds” ekranında backupların alınamaması ve restore jobların çalışmaması için ne kadar mühlet verileceÄŸi belirtilir. DiÄŸer ekranda monitor server seçilir. Burada birinsi sunucuyu izleme sunucusu olarak iÅŸaretledik.

Sonraki ekranları da düzenleyip kurulum işlemini bitirelim.

“DB Maintenance Plan1″ uygulaması oluÅŸturulduÄŸunda öncelikle WXX\KAFKA tarafındaki C:\LogShipOrnek\Logs klasöründe Kaynak_logshipping_init.bak isimli full backup oluÅŸturulur. Ve ikinci sunucu (DW) tarafında aÅŸağıdaki ifade aracılığıyla bu full backup ikinci sunucuya kopyalanır.

DECLARE @rv int
EXECUTE @rv = master.dbo.xp_cmdshell N'copy "\\Wxx\Logs\Kaynak_logshipping_init.bak" "C:\LogShipOrnek\LogBackupFile\Kaynak_init.bak"', no_output
SELECT @rv

Ardından ikinici sunucu tarafında bu full backup verdiğimiz klasörlere uygun olarak restore edilir.

RESTORE DATABASE [Kaynak] FROM  DISK = N'C:\LogShipOrnek\LogBackupFile\Kaynak_init.bak' WITH  FILE = 1,  NOUNLOAD ,  STATS = 10,  STANDBY = N'C:\LogShipOrnek\Data\undo_Kaynak.dat',  MOVE N'Kaynak_Data' TO N'C:\LogShipOrnek\Data\Kaynak.mdf',  MOVE N'Kaynak_Log' TO N'C:\LogShipOrnek\Data\Kaynak_log.ldf'

Ve yeni yaratılan bu database standby moduna geçirilir.

Log shipping modelinde kullanılan birinci ve ikinci sunucu tanımlamaları, en son hangi düzeyde backup alındığı ve restore edildiği gibi bilgiler msdb altındaki log_shipping_primaries, log_shipping_secondaries ve sysdbmaintplan_databases tablolarında tutulur.

Log shipping ayarlarını düzenlemek veya silmek için “DB Maintenance Plan1″ dosyası çift tıklanır ve açılan penceredeki “Log Shipping” sekmesi kullanılır.

Ayrıca Log Shipping sürecinin takibi için Enterprise Manager altındaki Management bölümündeki “Log Shipping Monitor” alanı kullanılır. Buradan en hangi backupların alındığı, kopyalandığı ve karşıya yüklendiÄŸi bilgileri öğrenilir.

Log shipping, backup job, copy job, restore job ve alert job olmak üzere 4 temel job oluÅŸturur. Backup Job, her primary database için primary server üzerinde oluÅŸturulur. Varsayılan olarak bu job 15 dk’da bir çalışır. Copy Job, secondary server üzerinde oluÅŸturulur. Bu job, primary server’den secondary server’e backup dosyalarını kopyalar. Restore Job, secondary server üzerinde oluÅŸturulur. Bu job, kopyalanmış olan backup dosyalarını secondary database’ler üzerinde restore eder. Alert Job, eÄŸer kullanıldıysa bu job monitor server üzerinde oluÅŸturulur. Bizim örneÄŸimizde monitor server olarak birinci sunucuyu seçtiÄŸimiz için bu job birinci sunucu üzerinde oluÅŸturuldu. Bu job, primary ve secondary database’ler tarafından paylaşımlı olarak kullanılıp backup ve restore iÅŸlemlerinin baÅŸarısız olması durumunda uyarı verir. EÄŸer monitor server kullanılmazsa alert job hem primary server hem de her secondary server üzerinde oluÅŸturulur. Primary server üzerindeki alert job, backup iÅŸlemi baÅŸarısız olduÄŸu zaman, secondary server üzerindeki alert job ise kopyalama ve restore iÅŸlemleri baÅŸarısız olduÄŸu zaman uyarı evrir.

SQL 2005′te log shipping iÅŸleminin nasıl yapılacağını da örneklendirelim. Bu sefer hem kaynak hem de hedef database aynı sunucu üzerinde bulunsun.

Primary Server -> AHMETKAYMAZ
Secondary Server -> AHMETKAYMAZ
Primary Database -> Kaynak1
Secondary Database -> Kaynak2

Log backupların alınacağı klasör ->C:\LogShipOrnek\Logs
Log backupların ikinci sunucu tarafından kopyalanacağı klasör -> LogsCopy
Kaynak2 veritabanının veri klasörü->C:\LogShipOrnek\Data
Kaynak2 veritabanının log klasörü->C:\LogShipOrnek\Log

SQL Server Management Studio aracını açıp Kaynak1 veritabanını saÄŸ tıklayarak “Tasks » Ship Transaction Logs” menüsünü Log Shipping penceresini açalım. Bu pencereye Kaynak1 veritabanının Properties bölümünden de eriÅŸilebilir.

Bu ekranda öncelikle Kaynak1 veritabanının birincil veritabanı olduÄŸunu belirtiyoruz. Ekrandaki “Backup Settings” buttonunu tıklayıp yedek dosyalarıyla ilgili ayarlar yapalım.

Yedek klasörlerinin aÄŸ ve yerel konumlarını girdikten sonra pencereyi kapatalım. Bir sonraki adım yedek sunucularını tanımlamaktır. Bunun için “Secondary server instances and databases” bölümünde Add düğmesini tıklayalım. “Secondary Database Settings” penceresinde ikinci sunucuyla ilgili ayarlar yapılır. Connect düğmesini tıklayıp ikinci sunucu olarak mevcut birinci sunucuyu göstereceÄŸiz. Yedek veritabanının adını Kaynak2 olarak giriyoruz ve bu veritabanı ÅŸu anda sistem üzerinde hazır olmadığı için birinci veritabanında full backup alınmasını ve Kaynak2 olarak restore edilmesini saÄŸlayacağız.

Ä°kinci sunucuyla ilgili ayarları da bitirdikten sonra bu süreci izleyecek bir monitor server tanımlayalım. Bunun için ana penceredeki “Use a monitor server instance” seçeneÄŸini iÅŸaretleyip Settings düğmesini tıklıyoruz. Monitor server olarak mevcut sunucuyu göstereceÄŸiz.

Artık SQL Server 2005 üzerinde log shipping işlemini hazırlamış olduk. OK düğmesini tıklayarak gerekli jobları oluşturalım. İşlemi başlattığımız anda Kaynak2 veritabanı salt-okunur modunda oluşturulur ve işlemleri yürütecek joblar yaratılır.

Son olarak şu notu ekleyelim SQL 2005 ve SQL 2000 arasında secondary/primary veya primary/secondary olarak log shipping kurulamaz.