DBCC CHECKDB çalıştırdım, ne kadar sürecek acaba?

Konu başlığında yazan sorunun cevabı tabii ki bu komutu çalıştırdığınız veritabanının büyüklüğüne, DBCC CHECKDB ile birlikte kullanacağınız parametrelere (NOINDEX, REPAIR_FAST gibi) ve donanım kaynaklarınıza bağlı.

Bununla birlikte, henüz DBCC CHECKDB'yi çalıştırmadan da, eğer daha önceden bir SQL Agent Job çalıştırdıysanız ne kadar sürdüğünü o Job'ın History'sinden de öğrenebilirsiniz.

Fakat benim özellikle paylaşmak istediğim şey ise, DBCC CHECKDB'yi çalıştırdıktan kısa bir süre sonra ne kadar süreceğini bir DMV yardımıyla görebileceğinizdir, bazılarını belki tahmin etti bile: sys.dm_exec_requests!

Ortamınıza uygun (ki umarım bir test ortamıdır bu!) DBCC CHECKDB komutunu çalıştırdıktan bir süre sonra başka bir Query Editor penceresinde aşağıdaki komutu çalıştırıp "percent_complete" ile "start_time" alanındaki değerlere bakıp, işlemin yaklaşık ne kadar sürede tamamlanacağını hesaplayabilirsiniz.


SELECT [session_id], [start_time], [status], [command], db_name([database_id]) AS [db_name], [wait_type], [wait_resource], [percent_complete] FROM sys.dm_exec_requests WHERE [session_id] > 50

Sorgunun sonucu

Yukarıdaki ekran görüntüsüne göre demek ki veritabanım için bu test ortamında DBCC CHECKDB sorgulamam ortalama 3 saat sürecek.

sys.dm_exec_requests DMV'sindeki "percent_complete" alanı aşağıdaki komutların tamamında işlemlerin ne kadarının tamalandığını söyleyecektir.

• ALTER INDEX REORGANIZE
• AUTO_SHRINK option with ALTER DATABASE
• BACKUP DATABASE
• DBCC CHECKDB
• DBCC CHECKFILEGROUP
• DBCC CHECKTABLE
• DBCC INDEXDEFRAG
• DBCC SHRINKDATABASE
• DBCC SHRINKFILE
• RECOVERY
• RESTORE DATABASE,
• ROLLBACK
• TDE ENCRYPTION

sys.dm_exec_requests DMV'si hakkında daha ayrıntılı bilgi için: http://technet.microsoft.com/en-us/library/ms177648.aspx

Ekrem Önsoy

DBCC CHECKDB kullanımı

DBCC CHECKDB'yi bir üretim ortamında kullanmanın pek de akıllıca olmadığını muhtemelen zaten görmüşsünüzdür veya bu yazıyla görüyorsunuz.

Bunu önceden biliyor olun veya yeni öğreniyor olun, eğer bu öğüdün içini doldurmadıysanız bu öneriyi kulak arkası edeceğiniz zamanlar da olacaktır.

Bu nedenle bu konuda size bir fikir vermek istedim! Test ortamlarımın birinde, sistem kaynaklarıyla ilgili bir test yaparken, testte DBCC CHECKDB'yi kullanmak istedim; çünkü bu komutun ne kadar kaynak canavarı olduğunun gayet farkındayım!

Öncelikle test ortamımdaki SQL Server Instance'ının doğru miktarda RAM kullandığından ve İşletim Sistemine ve diğer uygulamalara da yeterli RAM bıraktığımdan emin oldum.


SQL Server Instance'ının Max Server Memory ve Min Server Memory ayarlarını 6.144MB yaptım.


EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'max server memory (MB)', 6144
EXEC sp_configure 'min server memory (MB)', 6144
RECONFIGURE
EXEC sp_configure 'show advanced options', 0
RECONFIGURE

Yapmak istediğim test özellikle RAM hakkındaydı, bu kapsamda SQL Server servisini yeniden başlattım, Performance Monitor'ü açtım, özellikle SQL Server:Memory Manager'daki Target Server Memory (KB) ve Total Server Memory (KB) sayaçlarına diktim gözümü.

Performance Monitor, SQL Server: Memory Manager object

Hemen bu iki sayacın ne olduğunu da açıklayayım:
Target Server Memory (KB): İlgili SQL Server Instance'ınızın Data Cache için kullanabileceği azami değerdir.

Total Server Memory (KB): İlgili SQL Server Instance'ınızın an itibariyle Data Cache'te depoladığı veri miktarıdır.

Çok kısa bir sürede, 2 dakika içerisinde Total Server Memory (KB) sayacının değeri 6GB'e ulaştı! Yani SQL Server maksimum kullanabileceği RAM'i kullandı, sadece 2 dakikada. Bunun Production sunucunuzda olmasını istemezsiniz. Çünkü bu, tüm Data Cache/Buffer Pool'unuzdaki Page'lerin diske yazılıp RAM'dan çıkacağı anlamına gelir ve DBCC CHECKDB işleminden sonra uygulamanız vasıtasıyla yapılacak tüm rutin işlerin verileri diskten okuyacağı, yani çok fazla IO işlemi yapılabileceği demektir. Özellikle de ihtiyaçlarınızın küçük olmadığı, örneğin gün içinde Batch Requests/Sec sayacının 1000'den fazla bir değere sahip olduğu bir ortam düşünülürse ve sitem kaynaklarınız da uçsuz budaksız değilse bu pek de iç açıcı olmazdı.

Bu nedenle önerilere kulak vermenizi ve DBCC CHECKDB'yi, Restore testlerinizi (ki umarım yapıyorsunuzdur?) yaptığınız yerde çalıştırmanızı önemle tavsiye ederim!

Ekrem Önsoy