Yönettiğim ortamların birinde aşağıdaki gibi bir senaryo oluştu, durumu bir veritabanı yöneticisinin ağzından aktarayım:
- Veritabanının veri dosyalarından biri (*.mdf veya *.ndf) E: diskinde konumlandırılmış durumda,
- Bu veri dosyasının otomatik büyüme (auto growth) özelliği kapalı,
- Gece diskin kapasitesine dair bazı alarmlar gelmiş. Sabah kalktığımda kontrol ettim, diskte sadece veritabanı veri dosyası görünüyor ve dosya değiştirilme tarihi bugünden daha eski bir tarih, bu dosya büyümemiş bundan eminim. Diskin boyutu da alarmlarda belirtilenden farklı. Zaten alarmlar da belli bir süre sonra durmuş.
- Bunun nasıl bir açıklaması olabilir?
Bu durum, DBCC CHECKDB komutuyla bütünlük kontrolü yapılırken oluşabilir. Eğer yukarıdakine benzer bir senaryo yaşadıysanız, ki umuyorum ki düzenli olarak en azından haftada bir kere bu bakımı yapıyorsunuzdur, bunun nedeni DBCC CHECKDB komutunun oluşturduğu dahili "snapshot"tır.
Dahili "snapshot" veritabanı, DBCC CHECKDB komutunun çalıştırıldığı veritabanının her bir veri dosyası için aşağıdaki ekran görüntüsünde olduğu gibi ayrı ayrı "snapshot" dosyaları oluşturur. Örneğin aşağıdaki durumda diskin kapasitesi 500GB idi; ama iki tane 460GB'lık dosya görüyorsunuz, peki bu nasıl oluyor? Çünkü "snapshot" dosyalarının boyutları her ne kadar veri dosyalarıyla aynı görünse de, o kadar yeri birden rezerve etmiyorlar. Bu dosyalar, dosya sistemi seviyesinde "sparse" olarak işaretlenirler. DBCC CHECKDB komutu çalıştığı sürece ilgili veritabanında ne kadar çok işlem yapılıyorsa, bu "snapshot" dosyaları da o kadar dolar.
Yine bu senaryoda E: diskinin kapasitesi 500GB iken ve gerçek veritabanının veri dosyasının boyutu 460GB iken, gelen disk kapasite alarmları azar azar artarak geliyordu. Bunun nedeni de bir önceki paragrafta belirttiğim gibi "snapshot" dosyalarının DBCC CHECKDB komutu çalışmaya devam ederken gerçek veritabanı dosyasında yapılan değişiklikler nedeniyle, yine yapılan işlem hacmine göre dosyanın adım adım dolması.
Veritabanı bütünlük kontrolü tamamlandıktan sonra "snapshot" dosyaları otomatik olarak silinir. Eğer sunucu veritabanı bütünlük kontrolü sırasında beklenmedik bir şekilde kapanırsa, o zaman bu dosyalar silinmez ve hem diskte boş yere yer kaplarlar, hem de tekrar bütünlük kontrolü yapmaya kalktığınızda ilginç hatalarla karşılaşabilirsiniz.
DBCC CHECKDB komutu zaten çok IO yoğunluklu bir işlemdir. Bu nedenle muhakkak veritabanı sistemlerinizin "yatış" durumunda oldukları zaman çalıştırılmalıdırlar. DBCC CHECKDB komutunun neden yoğun zamanlarda çalıştırılmaması gerektiğine bir de bu yazımda anlattığım nedeni ekleyebilirsiniz. Çünkü DBCC CHECKDB komutu çalıştığı sürece veri dosyalarınızın bulunduğu disklerin doluluk oranları artacaktır. Eğer disklerde yeterince yer yoksa çeşitli sorunlar yaşayabilirsiniz, en kötü ihtimalle can sıkıcı ve korkutucu alarmlar alabilirsiniz, ki umarım disk doluluk oranlarınızı yakınen takip ediyorsunuzdur.
Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com
Hiç yorum yok:
Yorum Gönder