DBCC CHECKDB stratejisi: son başarılı kontrol, bölerek çalıştırma, sonucu yorumlama

Komut

-- Son basarili CHECKDB (1900-01-01 = hic yapilmamis):
SELECT name, DATABASEPROPERTYEX(name, 'LastGoodCheckDbTime') AS last_good_checkdb
FROM   sys.databases
WHERE  state_desc = N'ONLINE' AND name <> N'tempdb'
ORDER BY last_good_checkdb;

-- tempdb ihtiyaci tahmini:
DBCC CHECKDB (N'Musteri') WITH ESTIMATEONLY;

-- Buyuk DB'yi gunlere bol: allocation + catalog + tablo tablo CHECKTABLE
USE [Musteri];
DBCC CHECKALLOC (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKCATALOG (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKTABLE (N'dbo.Siparis') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- Sonucu tablo olarak al (hata satirlari, nesne ve sayfa bilgisi):
DBCC CHECKDB (N'Musteri') WITH TABLERESULTS, NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4;

Ne yapar?

Her veritabanında son başarılı CHECKDB zamanını gösterir, gereken tempdb alanını tahmin eder, büyük veritabanlarında kontrolü CHECKALLOC + CHECKCATALOG + CHECKTABLE parçalarına bölmeyi ve sonuçları satır olarak (nesne, index, sayfa) almayı sağlar.

Ne zaman kullanılır?

Bakım planını denetlerken, bakım penceresine sığmayan çok büyük veritabanlarında, 823/824 sonrası bozulmanın kapsamını belirlerken.

Dikkat

Sonuç satırındaki "repair_allow_data_loss is the minimum repair level" ifadesi onarımın veri sileceği anlamına gelir; önce sağlam yedekten restore (veya page restore) değerlendir. Yalnız nonclustered index (index_id > 1) hatalarıysa index'i drop/create etmek veri kaybı olmadan çözer. Hatayı bulduktan sonra disk alt sistemini incele. PHYSICAL_ONLY mantıksal kontrolleri atlar; arada bir tam CHECKDB şart. CHECKTABLE ile bölmede CHECKALLOC/CHECKCATALOG da çalıştırılmazsa kapsam eksik kalır.