DBCC CHECKDB tarafından raporlanan veritabanı tutarlılığı hatalarını giderme

Bu makalede, DBCC CHECKDB komutu tarafından bildirilen hataların nasıl giderileceği açıklanır.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 2015748

Belirtiler

DBCC CHECKDB (veya DBCC CHECKTABLE gibi diğer benzer komutlar) yürütüldüğünde, SQL Server hata günlüğüne aşağıdakine benzer bir ileti yazılır:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Bu ileti, bir onarım seçeneği kullanıldıysa kaç veritabanı tutarlılığı hatası bulunduğunu ve kaç hatanın onarıldığını gösterir. Bu ileti ayrıca Windows Uygulama Olay Günlüğü'ne EventID=8957 ile bilgi düzeyi iletisi olarak yazılır. Hatalar bildirilmiş olsa bile bu ileti bir bilgi düzeyi iletisidir.

"İç veritabanı anlık görüntüsü..." ile başlayan iletideki bilgiler yalnızca DBCC CHECKDB çevrimiçi çalıştırıldıysa ve veritabanı SINGLE_USER modunda değilse görüntülenir. Bunun nedeni, çevrimiçi DBCC CHECKDBiçin denetlenecek tutarlı bir veri kümesi sunmak için iç veritabanı anlık görüntüsünün kullanılmasıdır.

Bu makalede, DBCC CHECKDB tarafından bildirilen her belirli hatanın nasıl giderildiği anlatılmıyor; bunun yerine, hata bildirilirse genel yaklaşım ele alınıyor. Bu makaledeki CHECKDB ile ilgili tüm başvurular, aksi belirtilmedikçe, DBCC CHECKTABLE ve DBCC CHECKFILEGROUP için de geçerlidir.

Neden

DBCC CHECKDB komutu veritabanı sayfalarının, satırların, ayırma sayfalarının, dizin ilişkilerinin, sistem tablosu başvuru bütünlüğünün ve diğer yapı denetimlerinin fiziksel ve mantıksal tutarlılığını denetler. Bu denetimlerden herhangi biri başarısız olursa (seçtiğiniz seçeneklere bağlı olarak), hatalar bildirilir.

Bu sorunların nedeni dosya sistemi bozulması, temel donanım sistemi sorunları, sürücü sorunları, bellek veya depolama önbelleğindeki bozuk sayfalar ya da SQL Server ile ilgili sorunlar olabilir. Bildirilen hataların kök nedenini nasıl belirleyeceğiniz hakkında bilgi için bkz. Kök nedeni araştırın.

Çözüm

  1. Yedeklemeyi geri yüklemeye veya veritabanını başka bir şekilde onarmaya devam etmeden önce sistemdeki donanımla ilgili temel sorunları çözün. G/Ç yolu ile ilgili tüm cihaz sürücüsü, üretici yazılımı, BIOS ve işletim sistemi güncelleştirmelerini uygulayın. Sorunların kaynağını belirlemek ve çözmek için tam G/Ç yolunun (yerel makine, cihaz sürücüleri, depolama NIC'leri, SAN, arka uç depolama ve önbellek) ve belleğin (RAM) yöneticisiyle birlikte çalışın. Örnek olarak cihaz sürücülerini güncelleştirme ve G/Ç yolunun tamamının yapılandırmasını denetleme verilebilir. Kök nedenin nasıl araştırılacağına ilişkin ayrıntılar için bkz. Kök nedeni araştır.

  2. Kalıcı tutarlılık hataları bildirirse DBCC CHECKDB , en iyi çözüm bilinen iyi bir yedeklemeden verileri geri yüklemek olacaktır. Daha fazla bilgi için bkz. Geri Yükleme ve Kurtarma.

  3. Bilinen sorunlarla karşılaşmıyor olduğunuzdan emin olmak için en son SQL Server Toplu Güncelleştirmesi veya Hizmet Paketi'ni uygulayın. Veritabanı bozulması (tutarlılık hataları) ile ilgili düzeltilen bilinen sorunlar için Toplu Güncelleştirme veya Hizmet Paketi belgelerini gözden geçirin ve ilgili düzeltmeleri uygulayın. SQL Server 2022, 2019, 2017 için Ayrıntılı düzeltme listeleri içindeki belirli bir sürüm için tüm düzeltmeleri arayabileceğiniz merkezi bir konum.

  4. DBCC CHECKDB Hatalar aralıklı olarak oluşuyorsa, yani bir çalıştırmada görüntüleniyorsa ve bir sonraki çalıştırmada kayboluyorsa, disk önbelleği sorunlarıyla (cihaz sürücüsü veya diğer G/Ç yolu sorunu) karşılaşıyor olabilirsiniz. Sorunları yalıtmak ve çözmek için G/Ç yolunun sorumlularıyla birlikte çalışın. Örnek olarak cihaz sürücülerini güncelleştirme, G/Ç yolunun tamamının yapılandırmasını denetleme ve G/Ç yolu cihazlarında ve sisteminde üretici yazılımını ve BIOS'u güncelleştirme verilebilir.

  5. Yedekten geri yükleme mümkün değilse, CHECKDB kullanabileceğiniz bir hata onarma özelliğine sahiptir. İki onarım düzeyi vardır:

    • REPAIR_REBUILD - Veri kaybı olasılığı olmayan onarımlar gerçekleştirir.
    • REPAIR_ALLOW_DATA_LOSS - Veri kaybı olasılığı olan onarımlar yapar.

    Daha fazla bilgi için DBCC CHECKDB belgelerine bakın.

    Veritabanınızı mantıksal olarak tutarsız bir durumda bırakabileceğinden, veri kaybına izin ver seçeneğiyle onarma seçimini yaparken dikkatli olmanız gerekir. Çıkış, DBCC CHECKDB kullanılacak en düşük onarım düzeyinde bir öneride bulunur. CHECKDB öğesini REPAIR_ALLOW_DATA_LOSS ile daha fazla hata bildirilmeyene kadar birden çok kez çalıştırmak yaygın bir uygulamadır. Bunun nedeni, onarım bir hata kümesini düzelttiğinde diğer bozuk bağlantıların ortaya çıkarılabilmesidir. Ancak, temel neden çözümlenmediyse yeni hatalar ortaya çıkabilir. Bu nedenle, donanım veya dosya sistemi gibi sistem düzeyindeki sorunlar veri bozulmasına neden oluyorsa, bir yedeğin geri yüklenmesi veya onarım işleminden önce bu sorunların giderilmesi gerekir. Onarım tutarlılık hatalarını düzeltmezse veya veritabanı yedeklemesi bozuksa Microsoft destek mühendisleri bozuk verilerin fiziksel olarak kurtarılmasında yardımcı olamaz.

    DBCC CHECKDB çalıştırdığınızda, tüm hataları onarmak için gereken en düşük onarım seçeneğini belirten bir öneri sağlanır. Bu iletiler aşağıdaki çıkışa benzer:

    CHECKDB, 'mydb' veritabanında 0 ayırma hatası ve 15 tutarlılık hatası buldu.
    REPAIR_ALLOW_DATA_LOSS, DBCC CHECKDB (mydb) tarafından bulunan hatalar için en düşük onarım düzeyidir.

    Onarım önerisi, CHECKDB kaynaklı tüm hataları düzeltmeye çalışmak için gereken en düşük onarım düzeyidir. En düşük onarım düzeyi, bu onarım seçeneğinin tüm hataları düzeltdiği anlamına gelmez. Bazı hatalar basitçe düzeltilemez. Ayrıca, onarım işlemini birden çok kez çalıştırmanız gerekebilir. Bildirilen tüm hataların çözülmesi için bu onarım düzeyinin kullanılması gerekmez. Bu, CHECKDB tarafından REPAIR_ALLOW_DATA_LOSS ile yapılan tüm onarımların veri kaybına neden olmadığı anlamına gelir. Bir hatanın çözümünün veri kaybına neden olup olmadığını belirlemek için onarım çalıştırılmalıdır. Her bir tablo için onarım düzeyinin ne olduğunu daraltmaya yardımcı olan tekniklerden biri, hata bildiren herhangi bir tablo için DBCC CHECKTABLE kullanmaktır. Bu, belirli bir tablo için asgari onarım seviyesini gösterir.

    Uyarı

    CHECKDB onarım veya veri dışarı aktarma ya da içeri aktarma işlemi tamamlandıktan sonra el ile veri doğrulama gerçekleştirmeniz gerekir. Daha fazla bilgi için bkz. DBCC CHECKDB bağımsız değişkenleri. Onarımdan sonra veriler mantıksal olarak tutarlı olmayabilir. Örneğin, onarım (özellikle REPAIR_ALLOW_DATA_LOSS seçeneği) tutarsız veri içeren veri sayfalarının tamamını kaldırabilir. Böyle durumlarda, başka bir tabloyla yabancı anahtar ilişkisi olan bir tablo, üst tabloda karşılık gelen birincil anahtar satırları olmayan satırlarla sonuçlanabilir.

  6. Veritabanı şemasını komut dosyası olarak dışa aktarmayı deneyin. Betiği kullanarak yeni bir veritabanı oluşturun ve sonra bozuk veritabanından yeni veritabanına mümkün olduğunca çok veri dışarı aktarmak için BCP veya SSIS Dışarı/İçeri Aktarma Sihirbazı gibi bir araç kullanın. Bozuk bir tablodan veri dışarı aktarma işlemi başarısız olabilir. Böyle durumlarda, bu tabloyu atlayın, sonrakine geçin ve kaydedebileceğiniz kadarını kaydedin.

  7. DBCC CHECKDB tarafından oluşturulan belirli hatalar için aşağıdaki makaleleri gözden geçirin ve sağlanan adımları (varsa) izleyin. Burada bazı örnekler verilmiştir:

Veritabanı tutarlılığı hatalarının kök nedenini araştırın

Veritabanı tutarlılığı hatalarının kök nedenini belirlemek için şu yöntemleri göz önünde bulundurun:

  • Sistem düzeyi, sürücü veya diskle ilgili hatalar için Windows Sistem Olay Günlüğü'nü denetleyin ve bunları çözmek için donanım üreticinizle birlikte çalışın.
  • Bilgisayar ve/veya disk sistemi için donanım üreticileriniz tarafından sağlanan tanılamaları çalıştırın. Çoğu sistem, depolama aygıtları (sabit sürücüler), bellek, işlemciler, anakartlar, RAID dizileri ve daha birçok bileşen için BIOS/UEFI’de yerleşik tanılama araçları sunar.
  • Şunlardan emin olmak için donanım satıcınızla veya cihaz üreticinizle birlikte çalışın:
  • Tutarlılık hatalarının bildirildiği veritabanlarının bulunduğu sürücüde SQLIOSim gibi bir yardımcı program kullanmayı değerlendirin. SQLIOSim, disk sistemi için G/Ç bütünlüğünü test etmek için SQL Server Altyapısından bağımsız bir araçtır. SQLIOSim, SQL Server ile birlikte sunulur ve ayrıca indirilmesini gerektirmez. \MSSQL\Binn klasöründe bulunabilir.
  • Veritabanı bozulması (tutarlılık hataları) ile ilgili giderilmiş bilinen sorunlar için Toplu Güncelleştirme veya Hizmet Paketi belgelerini gözden geçirin ve ilgili düzeltmeleri uygulayın. SQL Server 2022, 2019, 2017 için Ayrıntılı düzeltme listeleri varsa, belirli bir sürüm için tüm düzeltmeleri arayabileceğiniz merkezi bir konum.
  • SQL Server tarafından bildirilen erişim ihlalleri veya doğrulama hataları gibi diğer hataları denetleyin. Bozuk veritabanlarıyla işlem yapılması genellikle erişim ihlali özel durumlarına veya assert hatalarına neden olur.
  • Veritabanlarınızın PAGE_VERIFY CHECKSUM seçeneğini kullandığından emin olun. Sağlama toplamı hataları bildiriliyorsa, bu, SQL Server diske sayfalar yazdıktan sonra tutarlılık hatalarının oluştuğunun bir göstergesidir. Bu nedenle G/Ç alt sisteminiz kapsamlı bir şekilde denetlenmelidir. Sağlama toplamı hataları hakkında daha fazla bilgi için bkz. SQL Server'da Msg 824 Sorunları Nasıl Giderilir.
  • ERRORLOG'da ileti 832 hatalarını arayın. Bu hatalar, sayfaların diske yazılmadan önce önbellekteyken zarar görmüş olabileceğini gösterebilir. Daha fazla bilgi için bkz. SQL Server'da Msg 832 Sorunlarını Giderme.
  • Başka bir sistemde, "temiz" (CHECKDB kaynaklı hata olmadan) olduğunu bildiğiniz bir veritabanı yedeğini ve ardından hatanın oluşturulduğu zamana yayılan işlem günlüğü yedeklemelerini geri yüklemeyi deneyin. "Temiz" veritabanı yedeklemesini ve işlem günlüğü yedeklemesini geri yükleyerek bu sorunu "yeniden oluşturabiliyorsanız" yardım için Microsoft Teknik Desteği'ne başvurun.
  • Veri Saflığı hataları, uygulamanın SQL Server tablolarına geçersiz verileri eklemesi veya güncelleştirmesiyle ilgili bir sorun olabilir. Veri Saflığı hatalarını giderme hakkında daha fazla bilgi için bkz. SQL Server 2005'te DBCC Hatası 2570 Sorunlarını Giderme.
  • chkdsk komutunu kullanarak dosya sisteminin bütünlüğünü denetleyin. Çalıştırmayınchkdsk SQL Server çalışırken. SQL Server denetlenen dosyalara yazıyorsa geçici dosya hataları bildirebilir. Ayrıca, /r veya /f gibi anahtarlar dosya baytlarını diskte farklı bir konuma taşıyabilir ve SQL Server da bu dosyalara yazıyor veya bu dosyalardan okuyorsa bu tür bir hareket bozulmaya neden olabilir. Bu nedenle, chkdsk komutunu çalıştırmadan önce SQL Server'ı durdurmayı unutmayın. Ayrıca, /r ve /f gibi onarım seçeneklerinde dikkatli olun. Bir onarım çalıştırmadan önce veritabanlarınızın yedeğini aldığınızdan emin olun. chkdsk tarafından disk hataları bulunursa bu seçenekler dosyaları bozabilir.

Daha Fazla Bilgi

DBCC CHECKDB söz dizimi ve komutun nasıl çalıştırılacağına ilişkin bilgi veya seçenekler için DBCC CHECKDB (Transact-SQL) konusuna bakın.

Eğer CHECKDB kullanılarak herhangi bir hata bulunursa, hata raporlama amacıyla ERRORLOG'da aşağıdaki iletiye benzer diğer iletiler bildirilir:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Hata bilgileri Watson hata raporlamasına gönderildi.

Hata raporlama için kullanılan dosyalar bir SQLDump<nnn>.txt dosyası içerir. Bu dosya, CHECKDB içinde bulunan hataların XML biçimindeki listesini içerdiğinden geçmişe dönük amaçlar için yararlı olabilir.

Bir veritabanı için DBCC CHECKDB öğesinin hata algılanmadan en son ne zaman çalıştırıldığını (son bilinen temiz CHECKDB) öğrenmek için SQL Server ERRORLOG'unu denetleyin. Kullanıcı veya sistem veritabanı için aşağıdakine benzer bir ileti arayın. Bu ileti, Windows Uygulama Olay Günlüğü'nde EventID = 17573 ile bilgi düzeyi iletisi olarak da yazılır:

'master' veritabanı için Tarih/Saat spid7s CHECKDB, Tarih/Saat22:11:11.417 (yerel saat) tarihinde hatasız tamamlandı. Bu yalnızca bilgilendirme amaçlı bir iletidir; kullanıcı eylemi gerekmez

  • Son güncelleştirme: