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

  • Makale

Bu makalede, komut tarafından bildirilen hataların nasıl giderildiği DBCC CHECKDB 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ürken, SQL Server hata günlüğüne aşağıdaki gibi 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ç tane 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 veritabanının modda olmadığı SINGLE_USER çevrimiçi çalıştırıldığında görüntülenirDBCC CHECKDB. Bunun nedeni, çevrimiçi DBCC CHECKDBbir iç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, tarafından DBCC CHECKDB bildirilen her bir hatanın nasıl giderildiği anlatılmamaktadır, bunun yerine hatalar bildirilirse genel yaklaşım ele alınmaktadır. Bu makaledeki tüm başvurularCHECKDB, belirtilmedikçe ve DBCC CHECKFILEGROUP için DBCC CHECKTABLE de geçerlidir.

Neden

komut veritabanı DBCC CHECKDB sayfalarının, satırların, ayırma sayfalarının, dizin ilişkilerinin, sistem tablosu bilgi tutarlılığı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 veya SQL Server ile ilgili sorunlar olabilir. Bildirilen hataların kök nedenini belirleme hakkında bilgi için bkz . Kök nedeni araştırma.

Çö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ı yalıtmak ve çözmek için tam G/Ç yolunun (yerel makine, cihaz sürücüleri, depolama NIC'leri, SAN, arka uç depolama ve önbellek) 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 nedeni denetleme hakkında daha fazla bilgi için bkz . Kök nedeni araştırma.

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

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

  4. DBCC CHECKDB Hatalar aralıklıysa, yani bir çalıştırmada görünürse ve bir sonraki çalıştırmada kaybolursa, 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 bakımcıları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ı ve BIOS'u güncelleştirme verilebilir.

  5. Bir yedekten geri yükleme mümkün değilse, CHECKDB kullanabileceğiniz hataları onarma özelliği vardır. İki onarım düzeyi vardır:

    • REPAIR_REBUILD - veri kaybı olasılığı olmayan onarımlar yapar.
    • 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 vererek onarım seçimi yaparken dikkatli olmanız gerekir. Çıkış, DBCC CHECKDB kullanılacak en düşük onarım düzeyinde bir öneride bulunur. Daha fazla hata raporlanana kadar birden çok kez çalıştırmak CHECKDBREPAIR_ALLOW_DATA_LOSS 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 gösterilebilir. Bu nedenle, donanım veya dosya sistemi gibi sistem düzeyindeki sorunlar veri bozulmasına neden oluyorsa, yedekleme veya onarım geri yüklemeden önce bu sorunların çözülmesi gerekir. Onarım tutarlılık hatalarını düzeltmezse veya veritabanı yedeklemesi bozuksa Microsoft destek mühendisleri bozuk verilerin fiziksel olarak kurtarılmasına yardımcı olamaz.

    komutunu çalıştırdığınızda DBCC CHECKDB, tüm hataları onarmak için gereken en düşük onarım seçeneğini belirtmek için 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 , (mydb) tarafından DBCC CHECKDB bulunan hataların en düşük onarım düzeyidir.

    Onarım önerisi, 'den CHECKDBgelen tüm hataları düzeltmeye çalışmak için 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 düzeltilemiyor. 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, tarafından yapılan tüm onarımların CHECKDB veri kaybına REPAIR_ALLOW_DATA_LOSS 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 tablo için onarım düzeyinin ne olduğunu daraltmaya yardımcı olan bir teknik, hata bildiren herhangi bir tablo için kullanmaktır DBCC CHECKTABLE . Bu, belirli bir tablo için en düşük onarım düzeyini gösterir.

    Uyarı

    Onarım veya veri dışarı aktarma veya içeri aktarma tamamlandıktan sonra CHECKDB 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çenek) tutarsız veriler içeren veri sayfalarının tamamını kaldırabilir. Bu gibi 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ı betik olarak oluşturmayı deneyin. Betiği kullanarak yeni bir veritabanı oluşturun ve sonra bozuk veritabanından yeni veritabanına mümkün olduğunca çok veri 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. Bu gibi durumlarda, bu tabloyu atlayın, sonrakine geçin ve yapabileceklerini kaydedin.

  7. tarafından DBCC CHECKDB oluşturulan belirli hatalar için aşağıdaki makaleleri gözden geçirin ve sağlanan adımları izleyin (varsa). İşte birkaç örnek:

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

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.
  • Şunlardan emin olmak için donanım satıcınızla veya cihaz üreticinizle birlikte çalışın:
  • Tutarlılık hatalarını bildiren veritabanlarının bulunduğu sürücüde SQLIOSim gibi bir yardımcı program kullanmayı göz önünde bulundurun. 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 teslim edilir ve ayrı bir indirme gerektirmez. \MSSQL\Binn klasöründe bulunabilir.
  • Veritabanı bozulması (tutarlılık hataları) ile ilgili olarak düzeltilen bilinen sorunlar için Toplu Güncelleştirme veya Hizmet Paketi belgelerini gözden geçirin ve ilgili düzeltmeleri uygulayın. Ayrıntılı düzeltme SQL Server 2022, 2019, 2017 için listelenmişse belirli bir sürüm için tüm düzeltmeleri arayabileceğiniz merkezi bir konum.
  • erişim ihlalleri veya onaylar gibi SQL Server tarafından bildirilen diğer hataları denetleyin. Bozuk veritabanlarına yönelik etkinlik genellikle erişim ihlali özel durumlarıyla veya onay hatalarıyla sonuçlanır.
  • Veritabanlarınızın seçeneğini kullandığından PAGE_VERIFY CHECKSUM emin olun. Sağlama toplamı hataları bildiriliyorsa bu, SQL Server diske sayfalar yazdıktan sonra tutarlılık hatalarının oluştuğunun 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'de Msg 824 Sorunlarını Giderme.
  • ERRORLOG'da ileti 832 hatalarını arayın. Bu hatalar diske yazılmadan önce önbellekte bulunan sayfaların zarar görmüş olabileceğini gösterebilir. Daha fazla bilgi için bkz. SQL Server'de Msg 832 Sorunlarını Giderme.
  • Başka bir sistemde, "temiz" olduğunu bildiğiniz bir veritabanı yedeklemesini (hata yok CHECKDB) 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 Destek'e başvurun.
  • Veri Saflığı hataları, uygulamanın SQL Server tablolarına geçersiz veri 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.

Daha fazla bilgi

Komutunu çalıştırma hakkında söz dizimi DBCC CHECKDB ve bilgileri veya seçenekleri hakkında ayrıntılı bilgi için bkz. DBCC CHECKDB (Transact-SQL).

kullanılarak CHECKDBherhangi 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 sqldump<nnn>.txt dosyası içerir. Bu dosya, xml biçiminde bulunan CHECKDB hataların listesini içerdiğinden geçmişe dönük amaçlar için yararlı olabilir.

Bir veritabanı için algılanan hatalar olmadan en son ne zaman DBCC CHECKDB çalıştırıldığını öğrenmek için (bilinen son temizlemeCHECKDB), kullanıcı veya sistem veritabanında aşağıdakine benzer bir ileti için ERRORLOG SQL Server denetleyin (bu ileti, Windows Uygulama Olay Günlüğü'nde EventID = 17573 ile birlikte bilgi düzeyi iletisi olarak yazılır):

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