Bakım çalışması sırasında disk alanının geçici olarak azalması durumu

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

Yedek alırken bütünlük kontrolü yapıyor musunuz?

Aralık ayı içerisinde 2 farklı yazı ile (biri ve diğeri) yedek almanın önemine değinmiştim. Bu yazı ile de, SQL Server'da yedek alırken kullanılabilecek önemli bir parametreye değinmek istiyorum.

Biliyorum, birçok kurumun maalesef hala belirlenmiş RPO ve RTO değerleri yok ve yedek alma işi sadece "yapılması gereken standart işlerden bir diğeri" gibi görülüyor. Bir felaket durumunda da tabiri caizse elde harddisk "verilerimizi nasıl kurtarabiliriz?" diye kapı kapı dolanan arkadaşları görüyoruz. Bu yazım ise tabii ki RPO ve RTO değerlerinin anlamını bilip, yedek almaya gerekli özeni gösteren kurum ve çalışanları için.

Konuya giriş yapmam için önece bazı terim ve kavramları izah etmem gerekiyor.

SQL Server'da veriler en küçük depolama birimi olan Page'lere kaydedilir. Page'ler diskte 8 kilobaytlık bir alan kaplar. Bir Page tablo yapınızda kullandığınız veritipleriniz ve verinize göre bir veya daha fazla kayıt içerebilir. SQL Server verileri Page'lere kaydettikten sonra otomatik ve rutin bir şekilde tekrar tekrar dönüp Page'lerin sağlık durumunu kontrol etmez ve Page'lerin sağlık ve bütünlük durumu fiziksel disk yapısındaki fiziksel bir sıkıntıdan, SQL Server'daki bir Bug'tan veya SQL Server'ın sağlıklı bir şekilde kapatılmaması gibi sebeplereden dolayı bozulabilir.

SQL Server 2005 ile birlikte Page'lerin veri bütünlüğünü kontrol seçenekleri arasına Checksum da katıldı. Öncesinde ise 2 seçenek vardı, ya bu kontrol hiç yapılmasın ya da Torn Page, bu seçenekler yeterince koruma sağlamıyordu, bu nedenle Checksum seçeneği geldi ve SQL Server 2005 ile birlikte varsayılan seçenek oldu. 

Page bütünlüğü için Checksum seçeneği kullanıldığında SQL Server tüm Page'in bütünlüğünü dikkate alarak bir Checksum hesaplar ve bunu da Page diske yazılırken Page'in içerisindeki Page Header'a "m_tornBits" etiketiyle kaydeder. Bu Page diskten okunurken Checksum tekrar hesaplanır ve "m_tornBits"teki değer ile (örnek değer: -1433260509) karşılaştırılır. Eğer eşleşme sağlanamazsa, o zaman SQL Server Error Log ve Windows Application Event Log'a 824 hata numarasıyla kaydedilir. Bu sayede üst seviye bütünlük kontrolü sağlanmış olur.

Torn Page'in yeterince koruma sağlamadığını söylemiştim, Checksum ile farkını belirginleştirmek için bir örnek vereyim. Sanırım birçoğunuz hayatınızın bir döneminde bir Hex Editor kullanmıştır. Örneğin Page doğrulama özelliği Torn Page olan bir sayfayı, ilgili veritabanını Offline duruma alarak bir Hex Editor ile değiştirebilirsiniz ve DBCC CHECKDB ile bütünlük kontrolü yapmadığınız sürece bu değişikliği kimse fark etmez. Fakat aynı Page Checksum doğrulamasıyla ayarlansaydı, Hex Editor ile değişiklik yapıp veritabanını tekrar Online duruma getirip ilgili kayıtları sorguladığınızda aşağıdaki gibi bir hata alırdınız:

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x34bf84e5; actual: 0x31268142). It occurred during a read of page (1:654) in database...

"Peki tüm bunların yedekleme ile ne ilgisi var kardeşim?" deme noktasına getirdiysem sizi, elbet bir nedeni var. Açıklayayım efendim.

SQL Server 2014 ile birlikte yedek alırken Checksum kontrolü seçeneği de geldi. Bu özellik 2 şekilde kullanılabilir.

1- Instance düzeyinde, "sp_configure" ile aşağıdaki gibi etkinleştirilebilir.

EXEC sp_configure 'backup checksum default', 1;
RECONFIGURE
GO

2- Her bir yedek alma komutuyla birlikte aşağıdaki gibi kullanılabilir:

BACKUP DATABASE X TO DISK = N'xxx' WITH CHECKSUM

Eğer birinci seçeneği kullanırsanız, veritabanı yedekleriniz varsayılan olarak Checksum kontrolü yapılarak alınır ve ilgili sistem tablolarında da kayıtları aşağıdaki gibi görürsünüz:

Bu kullanım size pratikte yukarıda bahsini ettiğim örnekte olduğu gibi bütünlük uyuşmazlığı yaşanan durumlarda haberdar olmanızı sağlayacaktır.

Örneğin test ortamımda bir sayfasını kasten bozduğum bir veritabanım var. Bu veritabanımın yedeğini aşağıdaki komut ile aldığımda hiçbir hata ile karşılaşmıyorum:

USE [master]
GO
BACKUP DATABASE [AdventureWorks2012_corruptionTest] TO DISK = N'C:\temp\corrupt_db.bak';
GO

Fakat aynı yedeği aşağıdaki komut ile alırsam (veya yukarıda 1. seçenek olarak belirttiğim gibi bu özelli Instance düzeyinde etkinleştirirsem)

USE [master]

GO

BACKUP DATABASE [AdventureWorks2012_corruptionTest] TO DISK = N'C:\temp\corrupt_db.bak' WITH CHECKSUM;

GO

O zaman aşağıdaki gibi bir hata alıyorum:

Msg 3043, Level 16, State 1, Line 6

BACKUP 'AdventureWorks2012_corruptionTest' detected an error on page (1:11984) in file 'C:\temp\AdventureWorks2012_Data.mdf'.

Msg 3013, Level 16, State 1, Line 6

BACKUP DATABASE is terminating abnormally.

Sonuç itibariyle, bu tür sorunlardan en kısa sürede haberdar olmak için:
- Tüm veritabanlarınızın Page Verification özelliğinin CHECKSUM olduğundan,
- SQL Server 2014 ve üzeri versiyonlardaki Instance'larınızda "backup checksum default" özelliğini etkinleştirdiğinizden,
- Tüm kritik veritabanlarınız için düzenli olarak DBCC CHECKDB kontrolü yaptığınızdan emin olun.

Olası bir bütünlük sorunundan ne kadar erken haberdar olursanız veri kaybı yaşama olasılığınız o kadar düşük olur. Bu nedenle uygulamalarınızın ihtiyaçlarını da düşünerek olabildiğince çok güvenlik önlemi almanız gerekiyor. Böyle derken kastettiğim şu Checksum ve DBCC CHECKDB gibi uygulamaların elbette bir kaynak bedeli var, CPU ve IO yükünü arttırırlar. Hangi işlemi ne zaman ve nasıl yaptığınız çok önemli. Operasyonlarınızı da aksatmak istemezsiniz, güvenlikten de feragat etmek istemezsiniz. Yarın üzülmemek için kendi ortamınızda, kendi uygulamalarınızın ihtiyaçlarını ve donanım kaynaklarınızı da dikkate alarak testlerinizi yapmalı ve bu uygulamaları devreye almalısınız.

Ekrem Önsoy

Veritabanı bütünlük kontrolünün kontrolü

Selamlar,

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