Tek bir komut ile:
DBCC TRACEON (3226, -1)
Bu şekilde çalıştırırsanız, bu Trace Flag'i Global olarak açmış olursunuz ve SQL Server Instance'ınız yeniden başlasa bile bu Trace Flag tekrar otomatik olarak açılır ve SQL Error Log'da da aşağıdaki gibi bir kayıt görürsünüz:
DBCC TRACEON 3226, server process ID (SPID) 107. This is an informational message only; no user action is required.
Biraz kestirme oldu. Açıklayayım. Bugüne kadar yüzlerce kez Log Shipping kurmuşumdur ve özellikle kritik veritabanlarının Transaction Log yedeklerini ortalama 5 dakikada bir, hatta duruma göre 1 dakikada bir aldırmamız gerekebilir. Böyle senaryolarda, hele ki aynı SQL Server Instance'ında daha başka Log Shipping kurulmuş veya Transaction Log yedekleri alınan veritabanları varsa ve bir de bu veritabanlarının sayısı çoksa, işte o zaman o SQL Server Instance'ının SQL Error Log, Default Trace ve Windows Application Event Log'larındaki kayıtların çok büyük bir bölümünü aşağıdakine benzer kayıtlar oluşturuyor demektir.
Log was backed up. Database:
Bir sorun yaşadığımızda, ilk bakacağımız yerlerin başında SQL Error Log, Windows Event Log'ları ve Default Trace dosyaları gelir. Eğer bu ortamların içeriğinin çoğu yukarıdaki gibi başarılı yedek alma mesajları dolduruyorsa, o zaman bunu yapmamız çok zorlaşıyor. Bu nedenle ben Log Shipping kurduğum ortamlarda bu Trace Flag'i muhakkak kullanırım. Bugüne kadar da olumsuz bir yanını görmedim.
Fakat şunu da belirtmem gerekir, örneğin geçenlerde Log Shipping kurduğum ortamlardan birindeki bir veritabanının Log Shipping'inin hata verdiğine dair mesajlar almaya başladım. Girip kontrol ettiğimde, çıplak gözle bakıldığında tüm yeni T-Log yedekleri hedefte var görünüyordu; fakat ilginç bir şekilde sıradaki T-Log Restore edilmeye çalışıldığında hata veriyordu. Hata mesajlarından, bu T-Log yedeğinden önce başka bir yedek olması gerektiği anlaşılıyordu, fakat T-Log yedek alma işinin de zaman aralığına baktığımda dosyalar gayet nizami görünüyordu. Aklıma hemen başka birisinin manuel olarak T-Log yedek alma olasılığı gelince SQL Error Log ile Default Trace'i incelemeye başladım ve tam da tahmin ettiğim gibi çıktı! Birisi benden habersiz T-Log yedeği almıştı. Eğer 3226 Trace Flag'i bu ortamda açık olsaydı, o zaman SQL Error Log'dan ve Windows Event Log'dan bu kayıtları göremezdim, ama tabii ki Best Practice olarak Default Trace'im açık olurdu ve buradan Trace Flag 3226 açık olsa da görebilirdim.
Bununla birlikte, 3226 Trace Flag'ini kullandığınızda eğer yedek alma işiniz hata verirse, SQL Error Log'da aşağıdaki gibi hata mesajlarını görmeye devam edersiniz:
BACKUP failed to complete the command BACKUP LOG
Hiç yorum yok:
Yorum Gönder