Aracılığıyla paylaş

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

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ğı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 veritabanının modda olmadığı SINGLE_USER çevrimiçi çalıştırıldığında görüntülenirDBCC CHECKDB. 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, tarafından DBCC CHECKDB bildirilen her belirli hatanın nasıl giderildiği anlatılmıyor, hata bildirilirse genel yaklaşım ele alınmıyor. Bu makaledeki tüm başvurularCHECKDB, belirtilmediği sürece ve DBCC CHECKFILEGROUP için DBCC CHECKTABLE de geçerlidir.

Neden

komutu DBCC CHECKDB veritabanı sayfalarının, satırların, ayırma sayfalarının, dizin ilişkilerinin, sistem tablosunun 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 ya da 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) 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 nedeni araştırma hakkında ayrıntılı bilgi için bkz . Kök nedeni araştırma.

  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 varsa 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 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ını ve BIOS'u güncelleştirme verilebilir.

  5. 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 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 vererek onarmayı tercih ederken dikkatli olmanız gerekir. Çıkış, DBCC CHECKDB kullanılacak en düşük onarım düzeyinde bir öneride bulunur. Daha fazla hata bildirinceye 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üklenmeden ö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.

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

    Onarım önerisi, içindeki tüm hataları CHECKDBdü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. Hata bildiren tüm tablolarda onarım düzeyinin ne olduğunu daraltmaya yardımcı olan DBCC CHECKTABLE bir teknik. 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 işlemi 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 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ın betiğini 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 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 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ı (varsa) izleyin. Burada bazı örnekler verilmiştir:

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. Sistemlerin çoğu depolama (sabit sürücüler), bellek, CPU'lar, sistem panoları, RAID dizileri ve diğer birden çok bileşen için BIOS/UEFI yerleşik tanılamaları sağlar.
  • Şunlardan emin olmak için donanım satıcınızla veya cihaz üreticinizle birlikte çalışın:
    • Donanım cihazları ve yapılandırma, Microsoft SQL Server Veritabanı Altyapısı Giriş/Çıkış gereksinimlerini onaylar.
    • G/Ç yolundaki tüm cihazlar için cihaz sürücüleri ile diğer destekleyici yazılım bileşenleri güncelleştirildi.
  • 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 gönderilir ve ayrı bir indirme gerektirmez. \MSSQL\Binn klasöründe bulunabilir.
  • 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 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 onaylar gibi diğer hataları denetleyin. Bozuk veritabanlarına yönelik etkinlik genellikle erişim ihlali özel durumlarına veya onay hatalarına neden olur.
  • 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 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ı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'da Msg 832 Sorunlarını Giderme.
  • Başka bir sistemde, "temiz" (hatasız CHECKDB) 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. SQL Server çalışırken çalıştırmayınchkdsk. SQL Server denetlenen dosyalara yazıyorsa geçici dosya hataları bildirebilir. Ayrıca, veya /f gibi /r 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, komutu çalıştırmadan önce SQL Server'ı durdurmayı chkdsk unutmayın. Ayrıca ve /fgibi /r onarım seçeneklerinde dikkatli olun. Bir onarım çalıştırmadan önce veritabanlarınızın yedeğine sahip olduğunuzdan emin olun. Bu seçenekler tarafından chkdskdisk hataları bulunursa dosyaları bozabilir.

Daha Fazla Bilgi

komutu ç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 bir 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ında hata algılanmadan en son çalıştırmanın DBCC CHECKDB (bilinen son temizleme CHECKDB) olduğunu öğrenmek için SQL Server ERRORLOG'u 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:

'ana' 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