DBCC CHECKDB: MS'e Tam Kılavuz SQL Server Veritabanı Sağlığı (2026)

DBCC CHECKDB SQL Server'nin ana veritabanı bütünlük aracı. Örneklerle nasıl kullanılacağını, bozulmaların nasıl giderileceğini ve performansın nasıl optimize edileceğini öğrenin.

3. DBCC CHECKDB'yi Çalıştırma: Adım Adım

3.1 Ön koşullar

Herhangi bir DBCC CHECKDB işlemini yürütmeden önce kontrol listesi aşağıdadır:

• Tam veritabanı yedeklemesi – Bozulmanın tespit edilmesi veya onarım işlemlerinin gerekli olması durumunda güvenlik ağınız olması açısından, bütünlük kontrollerini çalıştırmadan önce tam bir yedekleme oluşturun.
• Uygun izinler – DBCC CHECKDB komutlarını çalıştırmak için sysadmin veya db_owner izinlerine ihtiyacınız var
• Yeterli sistem kaynakları:
  • Bellek: Veritabanı boyutunun %25'i
  • Tempdb alanı: Veritabanı boyutunun %10-15'i
  • CPU: Bakım sırasında %50-70 kullanılabilirlik
  • G/Ç: Yoğun okuma işlemleri bekleyin
• Veritabanı erişilebilirliği – CHECKDB'nin tüm veritabanı sayfalarına okuma erişimi gerektirmesi nedeniyle veritabanınızın erişilebilir olduğunu ve kısıtlı bir durumda olmadığını doğrulayın

3.2 Temel Komut

M,ost Temel DBCC CHECKDB komutu üç yaygın varyasyonu içerir:

(1) Mevcut veritabanını kontrol edin (parametre yok):

DBCC CHECKDB

(2) Bir veritabanını adına göre kontrol edin:

DBCC CHECKDB ('YourDatabaseName')

(3) Bir veritabanını ID'ye göre kontrol edin:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Bu temel komut, belirtilen veritabanının tüm tablolarını, dizinlerini ve sistem yapılarını inceleyerek tam bir bütünlük denetimi gerçekleştirir. Boşluk içermeyen standart adlara sahip veritabanları için tırnak işaretlerini atlayabilirsiniz. Komut tamamlanana kadar çalışır, ilerleme mesajlarını ve nihai sonuçları görüntüler. Bu temel sözdizimi, daha küçük veritabanları için veya yeterli bakım zamanınız olduğunda mükemmel şekilde çalışır.

Aşağıda DBCC CHECKDB'nin çalıştırıldığına dair bir ekran görüntüsü bulunmaktadır SQL Server Yönetim Stüdyosu (SSMS):

3.3 Tamamlanmış Seçenekler

Aşağıda DBCC CHECKDB için tam seçenekler bulunmaktadır:

Kategoriler	seçenek	Tanım	DBCC CHECKDB örneği
Onarım Seçenekleri	REPAIR_REBUILD	Veri kaybı olmadan onarımlar (örneğin, dizin yeniden oluşturmaları)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Onarım yok. Sadece geriye dönük uyumluluk	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Tüm hataları onarır (veri kaybına neden olabilir)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kapsam Kontrolü	NOINDEX	Kümelenmeyen dizin denetimlerini atlar	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Yalnızca fiziksel depolama bütünlüğünü (sayfalar/kayıtlar) kontrol eder	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Mantıksal sütun değeri hatalarını (örneğin, geçersiz tarihler) kontrol eder	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Derin mantıksal kontroller (indeksli görünümler, XML/mekansal dizinler)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Çıkış Kontrolü	ALL_ERRORMSGS	Tüm hataları gösterir (varsayılan: nesne başına 200)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Bilgilendirici mesajları gizler	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performans	TABLOCK	Tablo kilitlerini kullanır (TempDB kullanımını azaltır ancak yazmaları engeller)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Paralellik ayarlarını geçersiz kılar	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Yarar	ESTIMATEONLY	Gerekli TempDB alanını tahmin eder. (gerçek bir kontrol yok)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Sonuçlarınızı Anlamak

DBCC CHECKDB, yürütülmesinin başarılı bir şekilde tamamlanıp tamamlanmamasına bağlı olarak farklı sonuçlar üretecektir. Bunları detaylı olarak açıklayalım.

4.1 CHECKDB Yürütme Başarıyla Tamamlandı

DBCC CHECKDB yürütmesi başarıyla tamamlanırsa, veritabanınızın sağlık durumuna bağlı olarak farklı türde sonuçlar bildirecektir.

4.1.1 Hiçbir Sorun Bulunamadı

DBCC CHECKDB herhangi bir sorun bulamazsa, şuna benzer bir çıktı göreceksiniz:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Bu sonuç, veritabanınızın tüm kontrol edilen yapılarda mükemmel bütünlüğü koruduğunu gösterir.

4.1.2 Bulunan Bozulma Hataları

DBCC CHECKDB bir bozulma hatası algıladığında, aşağıdaki yapıda bir hata mesajı bildirecektir:
Şiddet Seviyesi Rehberi:

• Seviye 16-19: Kullanıcı tarafından düzeltilebilen hatalar, genellikle küçük bozulmalar
• Seviye 20-24: Sistem hataları, acil müdahale gerektiren ciddi bozulmalar
• Seviye 25: Ölümcül hatalar, veritabanına erişilemeyebilir

Yaygın hatalar şunları içerir:

• Sayfa kontrol toplamı hataları (mesaj 824)
• Tahsis hataları (mesaj 8928)
• Dizin tutarlılık sorunları (mesaj 8964)

Mesaj yapısını anlamak, yanıt eylemlerine öncelik verilmesine ve uygun kurtarma stratejilerinin belirlenmesine yardımcı olur.

4.1.3 Genel Bilgi ve Uyarı Mesajları

Tüm DBCC CHECKDB çıktıları ciddi sorunları göstermez. Ayrıca bazı bilgilendirici ve uyarı mesajları da verebilir, bunlar şunlardır:

• Onarım ifadeleri – Küçük sorunları gidermek için onarım komutları öneren mesajlar
• Tahsis uyarıları – Veri erişimini etkilemeyen alan tahsisi hakkında uyarılar
• Performans önerileri – Endeks bakımı ve optimizasyonu için öneriler
• Bilgilendirme duyuruları – Hemen işlem gerektirmeyen genel durum mesajları

Bu mesajlar, acil eylem gerektiren kritik bozulmalar ile düzenli bakım pencereleri sırasında ele alınabilecek küçük sorunlar arasında ayrım yaparken değerli bakım rehberliği sağlar.

Örnek uyarı mesajı:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB Yürütme İptalleri

CHECKDB çeşitli sebeplerden dolayı çalışması sırasında durursa, bir hata mesajı bildirecek ve aşağıdaki durum koduyla bir hata kaydı ekleyecektir:

Eyalet	Tanım
0	Hata numarası 8930 oluştu. Bu, DBCC komutunu sonlandıran meta verilerde bir bozulma olduğunu gösterir.
1	8967 numaralı hata oluştu. Dahili bir DBCC hatası oluştu.
2	Acil mod veritabanı onarımı sırasında bir hata oluştu.
3	Bu, DBCC komutunu sonlandıran meta verilerde bir bozulma olduğunu gösterir.
4	Bir assert veya erişim ihlali tespit edildi.
5	DBCC komutunu sonlandıran bilinmeyen bir hata oluştu.

Örnek hata mesajı:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

Veya

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Örnek hata günlüğü:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Böyle bir durumda, aşağıdaki gibi alternatif gelişmiş seçenekleri deneyebilirsiniz: DataNumen SQL Recovery Veritabanınızdaki bozulmayı düzeltmek için.

5. Yolsuzluk Hatalarını Düzeltme

5.1 Yedekleme ve Geri Yükleme: En Güvenli Çözüm

DBCC CHECKDB bozulma hatalarını tespit ettiğinde, temiz bir yedeklemeden geri yükleme yapmak en güvenli ve en güvenli yoldur.ost güvenilir çözüm. Bu yaklaşım, altta yatan bozulma nedenlerini ortadan kaldırırken veri bütünlüğünü garanti eder. Geri yüklemeden önce, yedekleme bütünlüğünü kullanarak doğrulayın YALNIZCA DOĞRULAMAYI GERİ YÜKLE komutları ve veri kaybını en aza indirmek için nokta-zaman kurtarma seçeneklerini göz önünde bulundurun. Donanım sorunları veya yazılım hataları tekrarlanmayı önlemek için ek dikkat gerektirebileceğinden, kök neden analizi için bozulma ayrıntılarını belgelendirin.

5.2 Sayfa Düzeyinde Bozulma Çözümleri

Küçük veri bölümlerini etkileyen izole sayfa bozulması için, SQL Server Enterprise Edition, tam veritabanı restorasyonu olmadan belirli hasarlı sayfaları onaran sayfa geri yükleme yetenekleri sunar. Bu gelişmiş teknik, tam kurtarma modeli ve güncel günlük yedekleri gerektirir.

Adım adım sayfa geri yükleme işlemi:

1. Bozuk sayfayı tanımlayın CHECKDB hata mesajından (örneğin, sayfa 1:256)
2. Güncel bir günlük yedeği alın son işlemleri yakalamak için:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Bozuk sayfayı geri yükle m'denost son tam yedekleme:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Diferansiyel yedeklemeyi uygula (mümkün ise):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Tüm günlük yedeklerini uygula Sırasıyla, yeni oluşturulan da dahil olmak üzere:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Son bir günlük yedeği alın ve geri yükleyin sayfayı güncel hale getirmek için:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Kritik olmayan veriler için alternatif: Bozulma kritik olmayan verileri etkiliyorsa, bozulmuş yapıları yeniden oluşturmadan önce etkilenmeyen satırları yeni tablolara aktarabilirsiniz:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Dizin Bozulması Hızlı Düzeltmeleri

Dizin bozulması, altta yatan tablo verilerini etkilemeden dizin yapılarını yeniden oluşturan yeniden oluşturma işlemlerine genellikle iyi yanıt verir:

ALTER INDEX ALL ON YourTable REBUILD

Bu yaklaşım, kümelenmeyen dizin bozulması için özellikle iyi çalışır, çünkü yeniden oluşturma, kaynak tablo verilerinden dizin sayfalarını yeniden oluşturur ve tüm orijinal bilgileri korurken bozulmayı etkili bir şekilde ortadan kaldırır.

6. REPAIR_REBUILD ve REPAIR_ALLOW_DATA_LOSS'u kullanın

Önceki yöntemlerin hepsi başarısız olursa veya uygulanabilir olmazsa, veritabanını onarmak için REPAIR_REBUILD ve REPAIR_ALLOW_DATA_LOSS seçeneklerini kullanabilirsiniz.

6.1 REPAIR_REBUILD (Daha Güvenli Seçenek):

• İçin kullanmak: Endeks bozulması ve küçük tahsis hataları
• Veri güvenliği: Veri silinmeden bozulma düzeltmeleri denenir
• Risk seviyesi: Düşük – veri kaybı beklenmiyor
• Tipik senaryolar: Kümelenmeyen dizin bozulması, küçük meta veri sorunları
• Komut örneği: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Son Çare):

• İçin kullanmak: Yedeklemeler kullanılamadığında ciddi bozulmalar meydana gelir
• Veri güvenliği: Veritabanı işlevselliğini geri yüklemek için bozuk verileri silebilir
• Risk seviyesi: Yüksek – kalıcı veri kaybı mümkün
• Tipik senaryolar: Sayfa bozulması, sistem tablosu hasarı, tahsis zinciri hataları
• Komut örneği: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Bu Seçenekler İçin En İyi Uygulamalar:

• Daima test et mümkün olduğunda veritabanı kopyalarında onarım işlemleri
• Her zaman yedekle bu seçenekleri çalıştırmadan önce
• Tüm değişiklikleri belgelendirin uyumluluk ve sorun giderme amaçları için
• Veritabanını tek kullanıcı moduna ayarlayın onarım işlemlerini çalıştırmadan önce

Normalde şunu denemeliyiz ONARIM_YENİDEN OLUŞTUR ilk seçeneği deneyin. Başarısız olursa, o zaman deneyin ONARIM_ALLOW_DATA_LOSS seçeneği.

6.4 REPAIR_ALLOW_DATA_LOSS Sonuçları

6.4.1 Veri Kaybı Durumunda Onarım Başarılı Oluyor

Bazen ONARIM_ALLOW_DATA_LOSS seçenek başarılı olacak, ancak bazı verilerost onarımdan sonra.

Aşağıda bazı örnek mesajlar yer almaktadır:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Bunun nedeni, DBCC CHECKDB'nin bazı hasarlı kayıtları terk ederek veritabanını düzeltmesidir, ancak aslında most Bunlardan bazıları hala kurtarılabilir DataNumen SQL Recovery.

Örnek dosyalar:

SQL Server versiyon	Bozuk MDF dosyası	tarafından düzeltilen MDF dosyası DataNumen SQL Recovery
SQL Server 2014	Hata10_1.mdf (8909 numaralı mesajın ardından 8939 numaralı mesaj gelir) (600 kayıt lost (ONARIM_VERİ_KAYBINA_İZİN_VERİLİYOR)	Hata10_1_fixed.mdf (Kayıt yok lost)
SQL Server 2014	Hata10_2.mdf (8909 numaralı mesajın ardından 8939 numaralı mesaj gelir) (6000 kayıt (%50) lost (ONARIM_VERİ_KAYBINA_İZİN_VERİLİYOR)	Hata10_2_fixed.mdf (Sadece 100 kayıt lost)
SQL Server 2014	Error7mdf (100 kayıt lost (ONARIM_VERİ_KAYBINA_İZİN_VERİLİYOR)	Error7_fixed.mdf (Sadece bir kayıt lost)

6.4.2 Onarım Başarısız Oluyor – Profesyonel Çözümü Düşünün

If ONARIM_ALLOW_DATA_LOSS başarısız olursa, bir veya birden fazla hata mesajı çıktısı verecektir.

Aşağıda bazı örnekler verilmiştir:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Bu senaryolarda, aşağıdaki gibi profesyonel bir çözüm kullanmanız gerekir: DataNumen SQL Recovery veritabanınızı düzeltmek için.

Örnek Dosyalar

SQL Server versiyon	Bozuk MDF dosyası	tarafından düzeltilen MDF dosyası DataNumen SQL Recovery
SQL Server 2014	Hata1_3.mdf (Tek Mesaj 824)	Hata1_3_fixed.mdf
SQL Server 2014	Hata1_1.mdf (Sürekli Mesaj 824 hataları)	Hata1_1_sabit.mdf
SQL Server 2014	Hata1_2.mdf ((824. Mesajı 7909. Mesaj takip ediyor)	Hata1_2_fixed.mdf
SQL Server 2014	Hata4_1.mdf (8992 numaralı mesajın ardından 3852 numaralı mesaj geliyor)	Hata4_1_fixed.mdf
SQL Server 2014	Hata4_2.mdf (8992 numaralı mesajın ardından 3852 numaralı mesaj geliyor)	Hata4_2_fixed.mdf
SQL Server 2014	Hata5.mdf (Mesaj 8945)	Error5_fixed.mdf
SQL Server 2014	Hata6.mdf (Mesaj 2510)	Error6_fixed.mdf
SQL Server 2014	Hata2.mdf (Mesaj 2575)	Error2_fixed.mdf
SQL Server 2014	Hata11.mdf (Mesaj 8905)	Error11_fixed.mdf
SQL Server 2014	Hata3.mdf (Mesaj 5028)	Error3_fixed.mdf
SQL Server 2014	Error8mdf (Mesaj 5125)	Error8_sabit.mdf
SQL Server 2014	Hata9.mdf (Mesaj 3313)	Error9_fixed.mdf

7. En İyi Uygulamalar

7.1 Düzenli CHECKDB İşlemlerinin Planlanması

Kritik üretim veritabanları için haftalık DBCC CHECKDB yürütmesini, yüksek işlemli sistemler için günlük kontrollerle uygulayın. Performans etkisini en aza indirmek için düşük kullanım dönemlerinde işlemleri planlayın ve veritabanı boyutu ve bakım pencerelerine göre tam kontroller ve PHYSICAL_ONLY seçenekleri arasında dönüşümlü olarak geçiş yapmayı düşünün. SQL Server Ajan, merkezi izleme ve uyarı yetenekleri sağlarken tutarlı yürütmeyi garanti eder.

7.2 Performans Etki Yönetimi

DBCC CHECKDB işlemleri önemli sistem kaynakları tüketir ve potansiyel olarak eşzamanlı kullanıcı etkinliğini etkiler. Performans etki modellerini anlamak için kontroller sırasında CPU kullanımını, bellek tüketimini ve disk G/Ç'sini izleyin. Rutin kontroller için NOINDEX seçeneklerini kullanmayı ve aylık bakım pencereleri için tam doğrulamayı ayırmayı düşünün. Bütünlük kontrol dönemlerinde beklentileri yönetmek için sorgu zaman aşımı uzantılarını ve kullanıcı iletişim stratejilerini uygulayın.

7.3 Bakım Penceresi Planlaması

Yedekleme işlemleri, dizin yeniden oluşturma ve istatistik güncellemeleri gibi diğer bakım faaliyetleriyle DBCC CHECKDB planlamasını koordine edin. Performans düşüşüne veya zaman aşımı sorunlarına neden olabilecek kaynak yoğun işlemleri çakıştırmaktan kaçının. Veri hacimleri arttıkça tam bütünlük doğrulaması için yeterli zaman sağlayarak, veritabanı boyutu büyüme projeksiyonlarına dayalı bakım pencereleri planlayın.

7.4 Otomatik İzleme ve Uyarı

yapılandırma SQL Server DBCC CHECKDB bozulmayı tespit ettiğinde yöneticilere derhal bildirimde bulunmak için aracı uyarıları. Bütünlük kontrol sonuçlarını çıkaran ve kategorilere ayıran, trend analizi ve proaktif sorun tanımlamasını etkinleştiren günlük ayrıştırma çözümlerini uygulayın. Farklı bozulma ciddiyet seviyeleri için yanıt zaman çerçevelerini ve sorumlu personeli tanımlayan yükseltme prosedürleri oluşturun.

8. DBCC CHECKTABLE: Hafif Alternatif

8.1 CHECKDB Yerine CHECKTABLE Ne Zaman Kullanılır

DBCC CHECKTABLE, bireysel tablolar için odaklanmış bütünlük denetimi sağlar ve bu da onu aşağıdakiler için ideal hale getirir: tarBelirli veritabanı nesnelerinin sorun giderme ve bakımı alındı. CHECKTABLE'ı belirli tablolarla ilgili performans sorunlarını araştırırken, tam veritabanı kontrolleri arasında kritik iş tablolarını doğrularken veya zaman kısıtlamaları tam veritabanı doğrulamasını engellediğinde kullanın. Bu yaklaşım, tam CHECKDB işlemlerinin mevcut bakım pencerelerini aştığı büyük veritabanlarında özellikle değerli olduğunu kanıtlar.

8.2 DBCC CHECKTABLE Sözdizimi ve Örnekler

Temel CHECKTABLE komutu tarbelirli tabloları alır:

DBCC CHECKTABLE('YourTable')

CHECKDB gibi CHECKTABLE da performans optimizasyonu için NOINDEX ve bozulma çözümü için onarım parametreleri dahil olmak üzere çeşitli seçenekleri destekler. Ayrıca, kesin tablo tanımlaması için şema adlarını da belirtebilirsiniz:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Bu tarGeted yaklaşımı, iş saatleri boyunca sistem performansını korurken ayrıntılı bütünlük doğrulamasına olanak tanır.

8.3 Büyük Veritabanları için Performans Avantajları

CHECKTABLE işlemleri tam veritabanı kontrollerinden önemli ölçüde daha hızlı tamamlanır ve kritik tabloların daha sık bütünlük doğrulamasını mümkün kılar. Bu yaklaşım, haftalık veya aylık programlar için kapsamlı CHECKDB işlemlerini ayırırken temel iş tablolarının günlük doğrulanmasına olanak tanır. Azaltılmış kaynak tüketimi CHECKTABLE'ı minimum kullanıcı etkisi ile üretim ortamı yürütme için uygun hale getirir.

9. CHECKDB Başarısız Olduğunda

DBCC CHECKDB çeşitli senaryolarda başarısız olacaktır, bunlardan bazıları şunlardır:

• DBCC CHECKDB yürütme anormal bir şekilde sonlanır
• DBCC CHECKDB yürütmesi başarıyla tamamlanır, ancak onarım seçenekleri veritabanını onarma başarısız oldu.

Bu gibi durumlarda veritabanındaki bozulmaları düzeltmemize yardımcı olacak daha profesyonel bir araca ihtiyacımız oluyor.

9.1 Giriş DataNumen SQL Recovery

DataNumen SQL Recovery daha gelişmiş yetenekler sağlar:

• En iyi kurtarma oranı endüstride.
• Ciddi şekilde bozulmuş veritabanı dosyalarını kurtarın.
• Tablolar, dizinler, görünümler, tetikleyiciler, kurallar ve varsayılanlar dahil olmak üzere tüm veritabanı nesnelerini kurtarın.
• Saklı yordamları, skaler işlevleri, satır içi tablo değerli işlevleri ve çoklu ifade tablosu değerli işlevleri kurtarın.
• Kalıcı olarak silinen kayıtları kurtarın.
• Şifrelenmiş nesneleri şifresini çözün SQL Server veritabanları.
• MDF dosyalarını toplu olarak onarın.
• Kapsamlı onarım seçenekleri.
• Gelişmiş kayıt tutma ve raporlama.
• Herkes için destek SQL Server sürümleri.
• Teknik destek kullanılabilirliği
• Düzenli güncellemeler ve iyileştirmeler

9.2 Başarı Oranı Karşılaştırması

Kurtarma başarı oranları önemli ölçüde farklılık gösterir:

• DBCC CHECKDB & CHECKTABLE: 1.27% ortalama iyileşme oranı
• DataNumen: 92.6% Geri Dönüşüm Oranı

Aşağıda tam bir rekabet karşılaştırması bulunmaktadır:

9.3 Ciddi Yolsuzluktan Kurtulma

Ağır vakalar için gelişmiş yetenekler:

• Fiziksel olarak hasar görmüş depolamadan kurtarma
• Biçimlendirilmiş sürücülerden veya çökmüş sistemlerden kurtarma
• Disk görüntülerinden, yedekleme dosyalarından, sanal makine disk dosyalarından ve tempodan kurtarmarary dosyaları vb.

9.4 Profesyonel Çözümleri Ne Zaman Düşünmelisiniz?

• Yakın zamanda yedekleme mevcut değil
• DBCC CHECKDB başarısız oldu
• Ciddi yolsuzluk senaryoları
• Kritik iş verileriyle başa çıkma
• Zaman kritik olduğunda
• Maksimum iyileşmenin önemli olduğu durumlar

10. SSS

11. Sonuç

11.1 Önemli Noktaların Özeti

11.1.1 Temel DBCC CHECKDB Komutlarının Özeti

Kapsamlı veritabanı denetimi için temel DBCC CHECKDB sözdizimini öğrenin, performans optimizasyonu için NOINDEX ve PHYSICAL_ONLY seçeneklerini kullanın ve CHECKTABLE'ı anlayın. targeted tablo doğrulaması. Bu temel komutlar, erken bozulma tespiti ve sistematik bütünlük izlemeyi mümkün kılan proaktif veritabanı bakımının temelini oluşturur.

11.1.2 Kritik En İyi Uygulamalar Hatırlatması

Bütünlük kontrollerini çalıştırmadan önce her zaman güncel yedekleri koruyun, veritabanı kritikliğine göre düzenli CHECKDB işlemleri planlayın ve anında bozulma uyarıları için otomatik izleme uygulayın. Düzenli izleme yoluyla önlemenin reaktif yaklaşımları aştığını ve standart araçlar yetersiz kaldığında profesyonel kurtarma çözümlerinin değerli yedekleme seçenekleri sağladığını unutmayın.

11.2 DBCC CHECKDB ve Advanced Solutions'ı Ne Zaman Kullanmalısınız?

Rutin bütünlük izleme ve küçük bozulma çözümü için DBCC CHECKDB'yi kullanın ve yerleşik onarım yeteneklerinin ötesinde ciddi bozulma senaryoları için profesyonel kurtarma araçlarını saklayın. Karar çerçevesi yedekleme kullanılabilirliğini, veri kritikliğini, zaman kısıtlamalarını ve bozulma ciddiyetini dikkate almalıdır. Başarılı veritabanı yöneticileri, standart yaklaşımlar yetersiz kaldığında düzenli CHECKDB izlemeyi kapsamlı yedekleme stratejileri ve gelişmiş kurtarma seçeneklerinin farkındalığıyla birleştirir.

11.3 Veritabanı Yöneticileri için Hızlı Günlük Sağlık Kontrol Listesi

DBCC CHECKDB'yi çalıştırmanın ötesinde, aşağıdaki temel günlük uygulamalarla veritabanınızın optimum sağlığını koruyun:

1. Yedeklemenin Bütünlüğünü Doğrulayın

• Planlanan yedeklemelerin başarıyla tamamlandığını onaylayın
• Yedekleme okunabilirliğini doğrulamak için RESTORE VERIFYONLY'yi kullanın
• Tesis dışı kopyaların senkronize ve erişilebilir olduğundan emin olun

Ayrıca adresinden daha fazla bilgi alabilirsiniz. kapsamlı rehberimiz SQL Server yedek.

2. Tutarlılık Durumunu Gözden Geçirin

• Gecelik çalışmalardan otomatik DBCC CHECKDB sonuçlarını kontrol edin
• İzliyoruz SQL Server bozulma uyarıları için hata günlükleri
• Herhangi bir bütünlük hatasını derhal araştırın

3. Sunucu Sağlığını İzleyin

• CPU, bellek ve disk G/Ç ölçümlerini kontrol edin
• tempdb alanının kullanılabilirliğini doğrulayın
• Engellenen işlemleri ve uzun süre çalışan sorguları belirleyin

4. Kilitlenme Etkinliğini İzle

• Sistem sağlığı olaylarından çıkmaz grafiklerini inceleyin
• Sorunlu sorguları belirleyin ve geliştirme ekipleriyle birlikte optimize edin
• Kilitlenme mağduru sayısını ve işletme etkisini izleyin

Önemli Hatırlatıcılar

• Veritabanının sık sık küçülmesini önleyin – parçalanmayı artırır ve performansı düşürür. Yalnızca gerçekten gerekli olduğunda büyük veri silme işlemlerinden sonra küçültün.
• İzleme görevlerini otomatikleştirin kullanma SQL Server Kritik sorunlar için uyarılar içeren aracı işleri veya bakım planları.
• Afet kurtarma prosedürlerini test edin Yedeklemelerin geri yüklenebilir olmasını ve kurtarma hedeflerinin ulaşılabilir kalmasını sağlamak için haftalık olarak kontrol edin.

Bu günlük kontrol listesini düzenli DBCC CHECKDB işlemleriyle birleştirerek, proaktif izleme ve hızlı sorun yanıtı yoluyla veritabanı ortamınız için kapsamlı bir koruma oluşturursunuz.

12. Referanslar

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server Dökümanlar. Microsoft Şirketi.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “DBCC CHECKDB tarafından bildirilen veritabanı tutarlılık hatalarını giderin.” SQL Server Dökümanlar. Microsoft Şirketi.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors