Dün bir müşterimde sağlık bakımı çalışması yaparken bir şey dikkatimi çekti ve ilgili arkadaşlarla aramızda bu konuda konuştuk ve bir fikir ayrılığı oldu, daha doğrusu aslında hepimiz birlikte emin olamadık ve bu bir blog konusu olsun, biz de sonuç hakkında daha kesin bir fikir sahibi olalım ve herkesle de paylaşalım dedik.
Konumuz şuydu efendim, bir SQL Server Agent Job'ı ile DBCC CHECKDB komutu kullanılarak rutin olarak veritabanı bütünlük kontrolü yapılıyor. Örneğin:
Job içerisinde her bir veritabanı için ayrı bir Step var ve her birinde ayrı ayrı
Step1: DBCC CHECKDB('Veritabanı1')
Step2: DBCC CHECKDB('Veritabanı2')
Step3: DBCC CHECKDB('Veritabanı3')
...
Şeklinde tanımlanmış diyelim, şayet DBCC CHECKDB komutu ikinci adım için aşağıdaki gibi bir sonuç döndürürse ne olur?
CHECKDB found 0 allocation errors and 4 consistency errors in table 'tablo_adı' (object ID 1154103152).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'Veritabanı2'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Veritabanı2).
Esas merak ettiğimiz şey buydu: İlgili Job hata verir ve bu sayede Job'ın Notification bölümündeki ilgili operatöre e-posta gönderilir mi? Yoksa DBCC komutu böyle bir sonuç üretse de hatanın nedeni ve kaynağı DBCC komutu olmadığı için komut başarıyla tamamlanmış olur ve Job da başarıyla tamamlandığı için Notification bölümündeki operatöre e-posta göndermez mi? Sonuç olarak eğer böyle bir kontrol sonucu bir alarm üretilmezse bu kontrolün pek bir önemi kalmamış olacak ve bu da riskli bir durum oluşturacak.
"Peki bunu bugüne kadar hiç mi fark etmedin?" diyebilirsiniz, efendim ben bu kontrolü daha farklı şekilde yapıyorum. Benim yönettiğim ortamlarda yaptığım bütünlük testlerinin sonuçlarını kendime eposta ile göndertiyorum. Bu iş için sadece bu bütünlük Job'ı hata alırsa e-posta gelsin gibi bir mekanizma kullanmıyorum. Bu nedenle bu konu hakkında çok net bir fikrim yoktu.
Öncelikle şunu bilmek gerekiyor, bir veritabanı birçok şekilde Corrupt duruma düşebilir. Mesela bazen veritabanı Corrupt olduğunda hiç açılmıyor. Suspect durumda olabiliyor. Recovery Pending durumda olabiliyor. Bazen de Online gibi görünüyor, bazı tablolara ve verilere ulaşılabiliyor, fakat bazılarına ulaşılamıyor... Hatta aynı tablodaki bazı kayıtlara ulaşılabilip, bazılarına ulaşılamadığı da olabiliyor.
DBCC CHECKDB komutu da veritabanının içinde bulunduğu duruma göre bazen veritabanı hiç açılamadığı için daha baştan hata verip çalışmıyor, bazen de tarama yapılabiliyor; bunun sonucunda yukarıdaki gibi sonuçlar üretebiliyor. Bir veritabanının böyle birçok farklı Corruption senaryosu olduğunu bildiğim için, ben de dünkü tartışmamızda bu nedenle net olarak emin olamadım ve test etmek istedim.
BÖYLE BİR TESTİ KESİNLİKLE PRODUCTION, PRE-PRODUCTION, TEST ve DEV ORTAMLARINIZDA YAPMAYIN. Tamamen gözden çıkartabileceğiniz bir SQL Server Instance'ında ve ortamında yapabilirsiniz.
Test için:
- Testim için yalıtılmış test ortamlarımdan birindeki AdventureWorks2012 veritabanını kullandım.
- Veritabanımı Detach etmeden OFFLINE duruma getirdim.
- Veritabanımın veri dosyasının içeriğinde bir Hex Editör ile değişiklik yaparak test veritabanımı Corrupt duruma getirdim.
- Veritabanımı tekrar ONLINE duruma getirdim.
- Veritabanım tamamen sağlam görünüyordu. DBCC CHECKDB'yi çalıştırdığımda aşağıdaki sonucun oluştuğunu gözlemledim:
Bunun sonucunda, yukarıdaki ekran görüntüsünden de görülebileceği üzere DBCC CHECKDB komutu hata ile tamamlanmış sayıldı. Yani DBCC CHECKDB komutu bir veritabanında Corruption olduğuna dair bir sonuç üretirse, bu komutun kendi de hata ile tamamlanıyordu. Tabii hal böyle olunca, ilgili SQL Server Agent Job'ı da hata ile tamamlanmış oluyor ve Job'ın Notification bölümünde tanımlanan operatöre e-posta gönderiyor.
Önceden de belirttiğim gibi Corruption birçok şekilde gerçekleşebiliyor, bu nedenle her ne kadar bu test sonucunda en azından tablo/indeks boyutunda yaşanan bir Corruption sonucu DBCC CHECKDB komutunun hata ile tamamlanacağını ve ilgili Job'ın da hata üretip ilgili noktaları tetikleyeceğini görsek de, ben bu konuda hala temkinliyim. Özellikle kritik ortamlarımda DBCC CHECKDB sonuçlarını e-posta ile almayı yeğlerim.
Sevgiler,
Ekrem Önsoy
Hiç yorum yok:
Yorum Gönder