SQL Server Log Shipping Notları ve Detaylı Monitoring

14 January, 2014

Log shipping nasıl çalışır basitçe ifade etmek gerekirse; primary database üzerindeki transaction log backup bir klasöre yedeklenir, devamında bu klasör secondary database üzerindeki sql server agent ile secondary db’nin sunucusundaki klasöre kopyalanır ve son olarak bu klasördeki log’lar secondary database üzerine restore edilir.

Burada 3 job’dan söz edebiliriz;

  1. Log Backup Job (Primary sunucundaki klasöre)
  2. Copy Job (Primary sunucundaki klasörden Secondary sunucusundaki klasöre)
  3. Restore Job (Secondary sunucusuna kopyalanan log’ların secondary database üzerine restore edilmesi)

Her ne kadar eski technet dökümanlarında HA bölümünde yazılmış olsa da Log shipping bir disaster recovery çözümüdür, HA çözümlerinde ihtiyacımız olan anlık geri dönme, kesintisiz erişim söz konusu değildir. Bir database’in bütün loglarının felaket senaryolarında uzak veya yakın lokasyonlara yedeklenmesinden söz ediyoruz, bu nedenle bahsedilen secondary database’lere kullanıcılar otomatik olarak erişemez.

Bir kaç ön gereksinime dikkat etmekte fayda var;

  • Log Shipping sırasında bütün bu job’ları yerine getirecek olan SQL Server Agent servisinin sürekli çalışıyor olması gerekli, bu şu demek SQL Server Agent Service’i automatic olacak şekilde başlatın.
  • SQL Server Agent Service hesabı pimary sunucudaki paylaşıma açılacak klasörde read/write yetkisine sahip olmalı, aynı zamanda secondary’deki klasörde yine read/write yetkisi olmalı.
  • Log backup’ları sorun yaşamamak adına network’de bir share üzerinde tutun.
  • Primary DB’nin recovery model’i Full ya da Bulk-Logged olmalı, simple model log üretmediği için log shipping söz konusu olamaz.

Log Shipping konfigürasyonu sonrasında belki de backup çözümlerinde sürekli unutulan ya da önemsenmeyen monitoring aksiyonuna göz atmakta fayda var.

Log Shipping Monitoring

SQL Log Shipping için bir çok monitoring yönetim var, her monitoring konusunda olduğu gibi log shipping’de de önemli olan bunu takip etmek!

Kısaca başlıklar halinde bakacak olursak;

SQL Server Log Viewer

SQL Server Notification Job (e-mail attırma)

SQL Server Transaction Log Shipping, Status Report

Red Gate Transaction Log Shipping Monitor Tool

Primary database üzerinde;

Backup Job

SQL Server üzerindeki Log Viewer ile event’ler kontrol edilerek buradan bir çok bilgi toplanabilir.

Secondary database üzerinde;

Copy Job

Restore Job

Copy ve Restore Job’lar için yine Log Viewer ile log shipping’le ilgili event bilgileri elde edilebilir.

Monitor Server

Alert Job

Red Gate’in Log Shipping monitoring aracı oldukça işe yarayabilir, biraz incelersek basitçe kurulduğunu görebilirsiniz;

İlk olarak log shipping grubu ekleniyor, burada bahsedilen grup ürünün kendi içinde oluşturacağı belli bir log shipping grubu, ayrı ayrı log shipping grupları eklenerek farklı sunucular izlenebildiği için böyle bir yöntem belirlenmiş.


Grup içerisinde primary sunucu için konfigürasyonu tamamlıyorum;


Secondary sunucu için konfigürasyon adımlarını tamamlıyorum;


Son olarak Errors sekmesinde de varsa grupla ilgili problemlere göz atıyorum ve devamında kaydederek grup işlemini bitiriyorum.

Grup sorunsuz olarak tamamlandıktan sonra hemen izlemeye başlayabilirsiniz;

Örneğin aşağıda Primary sunucusu için 7 günlük bir rapor var;


Bu da secondary sunucu için 7 günlük rapor;


Sunucuların dışında database’lerin durumlarını da aşağıdaki ekranlarla detaylı şekilde izleyebiliyorum;





Tamamen ücretsiz bu tool’u bütün log shipping projelerinde kesinlikle tavsiye ederim. Birden çok job ve birden çok log shipping senaryosundan söz ediyorsak bir monitoring tool’u kullanmak kaçınılmaz.

Son olarak Red Gate’in tool içerisinde özel olarak kullandığı kavramlar ve detaylarına aşağıdaki tablodan erişebilirsiniz;

Keyword and Syntax Functionality
FREESPACE {drive letter}, {space in MB}
where:{drive letter} is the fixed drive letter;

{space in MB} is the minimum expected drive space in MB.

This keyword will raise an alert if the drive in question contains less free disk space than expected.Works with both the Production database and Standby Databases.
For example, to raise an alert when the E drive has less than two gigabytes of space remaining, use FREESPACE E, 2048.
LASTBACKUP {backup type}, {interval}
where:{backup type} denotes the type of backup – D for a full backup, L for transaction log backups;

{interval} denotes the maximum expected time since the last backup – in seconds (by default), minutes (suffixed with an M), hours (H) or days (D).

This keyword will raise an alert if no backups of the selected type have been performed in the expected period.Works only with the Production database.
For example, to raise an alert when the last transaction log backup was over 30 minutes ago, use LASTBACKUP L, 30m.
LASTRESTORE {restore type}, {interval}
where:{restore type} denotes the type of restore – D for a full restore, L for transaction log restore;

{interval} denotes the maximum expected time since the last restore – in seconds (by default), minutes (suffixed with an M), hours (H) or days (D).

This keyword will raise an alert if no restores of the selected type have been performed in the expected period.Works only with Standby Databases.
For example, to raise an alert when the last full restore was over 7 days ago, use LASTRESTORE D, 7d.
LOGBACKUPDURATION {duration}
where:{duration} is the maximum expected time for the transaction log backup to take – in seconds (by default), minutes (M), hours (H), or days (D).
This keyword will raise an alert if any transaction log backup takes longer than the supplied value.Works only with the Production database.
For example, to raise an alert when the last transaction log backup takes longer than 5 minutes, use LOGBACKUPDURATION 5m.
LOGRESTOREDURATION {duration}
where:{duration} is the maximum expected time for the transaction log restore to take – in seconds (by default), minutes (M), hours (H), or days (D).
This keyword will raise an alert if any transaction log restore takes longer than the supplied value.Works only with Standby Databases.
For example, to raise an alert when the last transaction log restore takes longer than 150 seconds, use LOGRESTOREDURATION 150.
LOGBACKUPSIZE {size in bytes}
where:{size in bytes} is the maximum expected size of the transaction log backup, in bytes.
This keyword will raise an alert if any transaction log backup is larger than the supplied value.Works only with the Production database.
For example, to raise an alert when the last transaction log backup exceeds 35MiB (36,700,160 bytes), use LOGBACKUPSIZE 36700160.
RESTORESPENDING {number of restores}
where:{number of restores} is the maximum number of outstanding restores expected.
This keyword will raise an alert if any standby database has more transaction log backups outstanding than the supplied value.Works only with Standby Databases.
For example, to raise an alert when any standby server has more than 12 pending restores, use RESTORESPENDING 12.

 

2,397 total views, 1 views today

{ 1 comment… read it below or add one }

Deniz July 16, 2015 at 18:31

Gerçekten çok teşekkürler başarılı bir makale olmuş elinize sağlık.

Reply

Leave a Comment

Previous post:

Next post: