DBCC CHECKDB (Transact-SQL)

  • Makale

Aşağıdaki işlemleri gerçekleştirerek belirtilen veritabanındaki tüm nesnelerin mantıksal ve fiziksel bütünlüğünü denetler.

  • Veritabanında DBCC CHECKALLOC komutunu çalıştırır.

  • Veritabanındaki tüm tablo ve görünümlerde DBCC CHECKTABLE komutunu çalıştırır.

  • Veritabanında DBCC CHECKCATALOG komutunu çalıştırır.

  • Veritabanındaki dizinlenmiş her görünümün içeriğini doğrular.

  • FILESTREAM komutunu kullanarak dosya sisteminde varbinary(max) verileri depolarken tablo meta verileri ve dosya sistemi dizin ve dosyaları arasındaki bağlantı düzeyi tutarlılığı doğrular.

  • Veritabanındaki Service Broker verilerini doğrular.

Bu, DBCC CHECKALLOC, DBCC CHECKTABLE veya DBCC CHECKCATALOG komutlarının DBCC CHECKDB komutundan ayrı olarak çalıştırılmasının gerekmediği anlamına gelir. Bu komutların gerçekleştirdiği denetimler hakkında daha ayrıntılı bilgi için, bu komutların açıklamalarına bakın.

Konu bağlantısı simgesi Transact-SQL Sözdizim Kuralları

Sözdizimi

DBCC CHECKDB 
[
    [ ( database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ] 
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

Bağımsız değişkenler

  • database_name | database_id | 0
    Bütünlük denetimlerinin çalıştırılacağı veritabanının adı veya kimliğidir. Belirtilmezse veya 0 belirtilirse, geçerli veritabanı kullanılır. Veritabanı adları tanımlayıcı kurallarına uymalıdır.

  • NOINDEX
    Kullanıcı tablolarının kümelenmemiş dizinlerinin yoğun denetimlerinin yapılmaması gerektiğini belirtir. Bu, genel çalıştırma süresini kısaltır. Sistem tabloları üzerinde bütünlük denetimleri her zaman yapıldığından, NOINDEX sistem tablolarını etkilemez.

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    DBCC CHECKDB komutundan, bulunan hataları düzeltmesini ister. Aşağıdaki onarım seçeneklerinden birini kullanmak için, belirtilen veritabanıtek kullanıcı modunda olmalıdır.

    • REPAIR_ALLOW_DATA_LOSS
      Rapor edilen tüm hataları onarmaya çalışır. Bu onarımlar bazı verilerin kaybolmasına neden olabilir.

    • REPAIR_FAST
      Yalnızca sözdiziminde geriye doğru uyumluluğu korur. Hiçbir onarım işlemi gerçekleştirilmez.

    • REPAIR_REBUILD
      Veri kaybetme olasılığı olmayan onarımları gerçekleştirir. Bunlar kümelenmemiş dizinlerdeki eksik satırları onarma gibi hızlı onarımlar veya bir dizini yeniden oluşturma gibi zaman alan onarımlar olabilir.

      REPAIR_REBUILD, FILESTREAM verilerinin söz konusu olduğu hataları onarmaz.

    Önemli notÖnemli

    REPAIR seçeneklerini yalnızca son çare olarak kullanın. Hataları onarmak için bir yedekten geri yüklemenizi öneririz. Onarım işlemleri tablolar üzerindeki veya arasındaki kısıtlamaların hiçbirini göz önüne almaz. Belirtilen tablo bir veya daha fazla kısıtlamada kullanılıyorsa, onarım işleminden sonra DBCC CHECKCONSTRAINTS komutunun çalıştırılmasını öneririz. REPAIR'i kullanmak zorundaysanız, kullanılacak onarım düzeyini bulmak için DBCC CHECKDB komutunu bir onarım seçeneği olmadan çalıştırın. REPAIR_ALLOW_DATA_LOSS düzeyini kullanırsanız, DBCC CHECKDB komutunu bu seçenekle çalıştırmadan önce veritabanının bir yedeğini almanızı öneririz.

  • ALL_ERRORMSGS
    Rapor edilen hataları nesneye göre görüntüler. Varsayılan olarak tüm hata iletileri gösterilir. Bu seçeneği belirtmenin veya çıkarmanın hiçbir etkisi olmaz. tempdb veritabanından üretilen iletiler dışında hata iletileri nesne kimliğine göre sıralanır.

    SQL Server Management Studio uygulamasında döndürülen en yüksek hata iletisi sayısı 1000'dir. Management Studio uygulamasını kullanırken, ALL_ERRORMSGS belirtildiğinde, hataların tam bir listesini almak için DBCC CHECKDB komutunu birkaç kez çalıştırmanız gerekebilir. ALL_ERRORMSGS seçeneğini belirttiğinizde, sqlcmd yardımcı programını kullanarak veya bir SQL Server Aracı işi zamanlayarak DBCC komutunu çalıştırmanız ve çıktıyı bir dosyaya yönlendirmeniz önerilir. Bu yöntemlerden herhangi biri, komutu bir kez çalıştırmanın tüm hata iletilerini raporlamasını sağlar.

  • EXTENDED_LOGICAL_CHECKS
    Uyumluluk düzeyi 100 (SQL Server 2008) veya daha yüksekse, dizinlenmiş bir görünümde, XML dizinlerinde ve varsa uzamsal dizinlerde mantıksal tutarlılık denetimleri gerçekleştirin.

    Daha fazla bilgi için bu konudaki daha sonra gelen "Açıklamalar" bölümündeki "Dizinlerde Mantıksal Tutarlılık Denetimleri Gerçekleştirme" kısmına bakın.

  • NO_INFOMSGS
    Tüm bilgi iletilerini kapatır.

  • TABLOCK
    DBCC CHECKDB komutunun iç bir veritabanı anlık görüntüsü kullanmak yerine kilitler almasına neden olur. Buna veritabanı üzerinde kısa dönemli özel bir kullanım (X) kilidi de dahildir. TABLOCK, DBCC CHECKDB komutunun ağır yük altındaki bir veritabanında daha hızlı çalışmasına neden olur, ancak DBCC CHECKDB çalışırken veritabanının eşzamanlı kullanım olanağını azaltır.

    TABLOCK gerçekleştirilen denetimleri sınırlar; veritabanında DBCC CHECKCATALOG çalıştırılmaz ve Service Broker verileri doğrulanmaz.

  • ESTIMATEONLY
    DBCC CHECKDB komutunu tüm diğer belirtilen seçeneklerle çalıştırmak için gereken tahmini tempdb alanını görüntüler. Gerçek veritabanı denetimi yapılmaz.

  • PHYSICAL_ONLY
    Denetlemeyi sayfa ve kayıt üstbilgilerinin fiziksel yapısının bütünlüğü ve veritabanının yer ayırma tutarlılığı ile sınırlar. Bu denetim, veritabanının fiziksel tutarlılığının küçük bir ek yük denetimini sağlamak için tasarlanmıştır, ancak yırtık sayfaları, sağlama toplamı hatalarını ve kullanıcı verilerinin tehlikeye atabilecek sık görülen donanım hatalarını da algılayabilir.

    DBCC CHECKDB komutunun tam bir çalıştırmasının tamamlanması, önceki sürümlere göre çok daha uzun sürebilir. Bu davranış şunlar nedeniyle görülür:

    • Mantıksal denetimler daha kapsamlıdır.

    • Alttaki bazı yapıların denetlenmesi daha karmaşıktır.

    • Bu yeni özellikleri dahil etmek için pek çok yeni denetim konmuştur.

    Dolayısıyla PHYSICAL_ONLY seçeneğini kullanmak, büyük veritabanlarında çok daha kısa bir DBCC CHECKDB çalıştırma süresine neden olabilir ve profesyonel sistemlerde sık kullanılması önerilir. Yine de dönemsel olarak tam bir DBCC CHECKDB çalıştırmasının gerçekleştirilmesini öneriyoruz. Bu çalıştırmaların sıklığı ayrı ayrı iş ve üretim ortamlarına özgü etmenlere bağlıdır.

    PHYSICAL_ONLY her zaman NO_INFOMSGS komutunu gerektirir ve onarım seçeneklerinden herhangi biriyle kullanılamaz.

    [!NOT]

    PHYSICAL_ONLY komutunu belirtmek, DBCC CHECKDB komutunun FILESTREAM verilerinin tüm denetimleri atlamasına neden olur.

  • DATA_PURITY
    DBCC CHECKDB komutunun veritabanında geçerli olmayan veya aralık dışı sütun değerlerini denetlemesine neden olur. Örneğin, DBCC CHECKDB, datetime veri türü için kabul edilebilir olan aralık değerlerinden daha büyük veya daha küçük tarih ve saat değerleri olan sütunları ya da geçerli olmayan ölçek veya kesinlik değerleri olan decimal veya yaklaşık sayısal veri türü sütunlarını algılar.

    SQL Server 2005 veya daha yenisinde oluşturulan veritabanları için sütun değeri bütünlüğü denetimleri varsayılan olarak etkinleştirilir ve DATA_PURITY seçeneğini gerektirmez. SQL Server uygulamasının daha önceki sürümlerinden yükseltilmiş veritabanları için sütun değeri denetimleri, DBCC CHECKDB WITH DATA_PURITY komutu veritabanında hatasız olarak çalıştırılıncaya kadar varsayılan olarak etkinleştirilmez. Bu işlemden sonra DBCC CHECKDB komutu, varsayılan olarak sütun değeri bütünlüğünü denetler. CHECKDB komutunun veritabanını SQL Server uygulamasının daha önceki sürümlerinden yükseltmeden nasıl etkilenebileceği hakkında daha fazla bilgi için, bu konuda ilerideki Açıklamalar bölümüne bakın.

    PHYSICAL_ONLY belirtilirse, sütun bütünlüğü denetimleri gerçekleştirilmez.

    Bu seçeneğin raporladığı doğrulama hataları, DBCC onarım seçenekleri kullanılarak düzeltilemez. Bu hataları el ile düzeltme hakkında daha fazla bilgi için, bkz. Bilgi Bankası makalesi 923247: DBCC hata 2570 SQL Server 2005'te sorun giderme.

Açıklamalar

Daha önceki SQL Server sürümlerinde, tablo başına ve dizin başına satır sayısı ve sayfa sayısı değerleri yanlış hale gelebilir. Belirli koşullar altında bu değerlerin biri veya birkaçı eksi duruma bile gelebilir. SQL Server 2005 ve daha sonraki sürümlerde bu değerler her zaman doğru tutulmaktadır. Bu yüzden SQL Server 2005 ve sonraki sürümlerde oluşturulan veritabanları hiçbir zaman yanlış değer içermemelidir; ancak SQL Server 2005 ve daha yeni sürümlere yükseltilen veritabanları içerebilir. Bu, veritabanında depolanan herhangi bir verinin bozulması değildir. DBCC CHECKDB, bu sayımlar eksiye döndüğünde bunu algılayacak şekilde geliştirilmiştir. Eksi sayımlar algılandığında, DBCC CHECKDB çıktısı bir uyarı ve sorunu düzeltmek için DBCC UPDATEUSAGE komutunun çalıştırılması önerisini içerir.

DBCC CHECKDB devre dışı bırakılan dizinleri incelemez. Devre dışı bırakılan dizinler hakkında daha fazla bilgi için, bkz. Dizinler ve kısıtlamalar devre dışı bırakma.

Kullanıcı tanımlı bir tür bayt sıralı olarak işaretlenmişse, kullanıcı tanımlı türün yalnızca bir serileştirilme biçimi olmalıdır. Bayt sıralı kullanıcı tanımlı türlerin tutarlı bir serileştirilme biçiminin olmaması, DBCC CHECKDB çalıştırıldığında 2537 hatasına neden olur. Daha fazla bilgi için, bkz. Kullanıcı tanımlı türü gereksinimleri.

Kaynak veritabanı yalnızca tek kullanıcılı modda değiştirilebildiğinden, DBCC CHECKDB komutu bu veritabanının üzerinde doğrudan çalıştırılamaz. Ancak, DBCC CHECKDB komutu ana veritabanı üzerinde çalıştırıldığında, ikinci bir CHECKDB komutu da dahili olarak Resource veritabanı üzerinde çalıştırılır. Bu, DBCC CHECKDB komutunun ek sonuçlar döndürebileceği anlamına gelir. Komut hiçbir seçenek belirtilmediğinde veya PHYSICAL_ONLY veya ESTIMATEONLY seçeneği belirtildiğinde ek sonuç kümeleri döndürür.

SP2'den önceki SQL Server 2005 sürümlerinde, DBCC CHECKDB komutunu çalıştırmak SQL Server sürümünün plan önbelleğini temizler. Plan önbelleğini temizlemek, tüm sonraki yürütme planlarının yeniden derlenmesine neden olur ve sorgu performansında ani, geçici bir düşüşe neden olabilir. SP2 ve sonrasında, DBCC CHECKDB komutunu yürütmek plan önbelleğini temizlemez.

Dizinlerde Mantıksal Tutarlılık Denetimleri Gerçekleştirme

Dizinlerde mantıksal tutarlılık denetimi, veritabanının uyumluluk düzeyine göre aşağıdaki gibi değişkenlik gösterir:

  • Uyumluluk düzeyi 100 (SQL Server 2008) veya yukarısıysa:

    • NOINDEX belirtilmedikçe, DBCC CHECKDB, tek bir tabloda ve tablonun kümelenmemiş tüm dizinlerinde hem fiziksel hem de mantıksal tutarlılık denetimleri gerçekleştirir. Ancak, XML dizinlerinde, uzamsal dizinlerde ve dizinli görünümlerde varsayılan olarak yalnızca fiziksel tutarlılık denetimleri gerçekleştirilir.

    • WITH EXTENDED_LOGICAL_CHECKS belirtilirse, mantıksal denetimler dizinli bir görünümde, XML dizinlerinde ve varsa uzamsal dizinlerde gerçekleştirilir. Varsayılan olarak fiziksel tutarlılık denetimleri, mantıksal tutarlılık denetimlerinden önce gerçekleştirilir. NOINDEX de ayrıca belirtilirse, yalnızca mantıksal denetimler gerçekleştirilir.

      Bu mantıksal tutarlılık denetimleri, dizin nesnesinin dahili dizin tablosu ile bu tablonun başvurduğu kullanıcı tablosu arasındaki tutarlılığı denetler. Dışta kalan satırları bulmak için, dahili tabloların ve kullanıcı tablolarının tam bir kesişimini gerçekleştirmek için dahili bir sorgu oluşturulur. Bu sorguyu çalıştırmanın performans üzerinde çok ağır bir etkisi olabilir ve ilerleyişi izlenemez. Dolayısıyla, WITH EXTENDED_LOGICAL_CHECKS seçeneğini yalnızca fiziksel bozulma ile ilişkisiz dizin sorunlarından kuşkulanıyorsanız veya sayfa düzeyi bir sağlama toplamı kapatıldıysa ve sütun düzeyinde donanım bozulmasından kuşkulanıyorsanız belirtmenizi öneririz.

    • Dizin filtrelenmiş bir dizinse, DBCC CHECKDB, dizin girişlerinin filtreleme koşulunu karşıladığını doğrulamak için tutarlılık denetimleri gerçekleştirir.

  • Uyumluluk düzeyi 90 veya daha azsa, NOINDEX belirtilmedikçe DBCC CHECKDB, tek bir tabloda veya dizinli bir görünümde ve görünümün tüm kümelenmemiş XML dizinlerinde hem fiziksel hem de mantıksal düzey tutarlılık denetimleri gerçekleştirir. Uzamsal dizinler desteklenmez.

Veritabanı uyumluluk düzeyi hakkında daha fazla bilgi için

Dahili Veritabanı Anlık Görüntüsü

DBCC CHECKDB, bu denetimleri gerçekleştirmek için gereken işlem tutarlılığı için dahili bir veritabanı anlık görüntüsü kullanır. Bu yöntem, bu komutlar çalıştırıldığında tıkanma ve eşzamanlılık sorunlarını önler. Daha fazla bilgi için, bkz. Veritabanı Snapshot (Transact-sql) seyrek dosya boyutunu görüntülemek ve DBCC (Transact-sql) konusundaki DBCC Dahili Veritabanı Anlık Görüntüsü Kullanımı bölümü. Bir anlık görüntü oluşturulamıyorsa veya TABLOCK belirtilirse, DBCC CHECKDB gerekli tutarlılığı elde etmek için kilitleri alır. Bu durumda yer ayırma denetimleri gerçekleştirmek için bir özel kullanım veritabanı kilidi ve tablo denetimleri gerçekleştirmek için paylaşılan tablo kilitleri gerekir.

Dahili bir veritabanı anlık görüntüsü oluşturulamazsa, DBCC CHECKDB komutu, master üzerinde çalıştırıldığında başarısız olur.

DBCC CHECKDB komutunu tempdb üzerinde çalıştırmak herhangi bir yer ayırma veya katalog denetimi yapmaz ve tablo denetimleri gerçekleştirmek için paylaşılan tablo kilitleri alması gerekir. Bunun nedeni, performans gerekçeleriyle tempdb veritabanı anlık görüntülerinin olmamasıdır. Bu, gerekli işlem tutarlılığının sağlanamayacağı anlamına gelir.

FILESTREAM Verilerini Denetleme ve Onarma

FILESTREAM bir veritabanı ve tablo için etkinleştirildiğinde, isteğe bağlı olarak varbinary(max) ikili büyük nesnelerini (BLOB'lar) dosya sisteminde depolayabilirsiniz. DBCC CHECKDB komutu BLOB'leri dosya sisteminde depolayan bir veritabanı üzerinde kullanılırken, DBCC, dosya sistemi ve veritabanı arasındaki bağlantı düzeyi tutarlılığı denetler.

Örneğin, tablo FILESTREAM özniteliğini kullanan bir varbinary(max) sütunu içeriyorsa, DBCC CHECKDB dosya sistemi dizin ve dosyaları ile tablo satırları, sütunları ve sütun değerleri arasında bire bir eşleşme olup olmadığını denetler. REPAIR_ALLOW_DATA_LOSS seçeneğini belirtirseniz, DBCC CHECKDB bozulmayı onarabilir. DBCC, FILESTREAM bozulmasını onarmak için, varsa dosya sistem verileri eksik olan tablo satırlarını siler.

En İyi Yöntemler

Profesyonel sistemlerde PHYSICAL_ONLY seçeneğini sık kullanmanızı öneririz. PHYSICAL_ONLY komutunu kullanmak büyük veritabanlarında DBCC CHECKDB çalışma zamanı süresini önemli oranda kısaltabilir. Ayrıca, dönemsel olarak DBCC CHECKDB komutunu, seçenek kullanmadan çalıştırmanızı öneriyoruz. Bu denetimlerin hangi sıklıkla çalıştırılması gerektiği işletmelere ve üretim ortamlarına bağlıdır.

Paralel Olarak Nesne Denetleme

DBCC CHECKDB, varsayılan olarak nesneleri paralel denetler. Paralellik derecesi, sorgu işleyici tarafından otomatik olarak belirlenir. Paralelliğin en yüksek derecesi, aynı paralel sorgular gibi yapılandırılır. DBCC denetimi için kullanılabilen en yüksek işlemci sayısını kısıtlamak için sp_configure komutunu kullanın. Daha fazla bilgi için, bkz. Maksimum ölçüde parallelism sunucu yapılandırma seçeneği yapılandırmak. Paralel denetleme ayrıca izleme bayrağı 2528 kullanılarak da devre dışı bırakılabilir. Daha fazla bilgi için, bkz. İzleme Bayrakları (Transact-SQL).

DBCC Hata İletilerini Anlama

DBCC CHECKDB komutu tamamlandıktan sonra SQL Server hata günlüğüne bir ileti yazılır. DBCC komutu başarıyla çalıştırıldıysa, ileti başarı durumu ve komutun çalıştığı süreyi gösterir. DBCC denetimi tamamlamadan önce bir hata nedeniyle durursa, ileti komutun sonlandırıldığını, bir durum değerini ve komutun çalıştığı süreyi gösterir. Aşağıdaki tablo iletiye dahil edilebilecek durum değerlerini listelemekte ve açıklamaktadır.

Durum

Açıklama

0

8930 numaralı hata oluştu. Bu, DBCC komutunu meta verilerdeki bir bozulmanın sonlardırdığını gösterir.

1

8967 numaralı hata oluştu. Dahili bir DBCC hatası vardı.

2

Acil mod veritabanı onarımı sırasında bir hata oluştu.

3

Bu, DBCC komutunu meta verilerdeki bir bozulmanın sonlardırdığını gösterir.

4

Bir önerme veya erişim ihlali algılandı.

5

DBCC komutunu sonlandıran bilinmeyen bir hata oluştu.

Hata Raporlama

DBCC CHECKDB bir bozulma hatası algıladığında SQL Server LOG dizininde bir döküm dosyası (SQLDUMPnnnn.txt). SQL Server örneği için Özellik Kullanımı veri koleksiyonu ve Hata Raporlama özellikleri etkinleştirildiğinde, dosya otomatik olarak Microsoft şirketine iletilir. Toplanan veriler, SQL Server işlevselliğini iyileştirmek için kullanılır.

Döküm dosyası DBCC CHECKDB komutunun sonuçlarını ve ek tanılama çıktılarını içerir. Erişim SQL Server hizmet hesabı ve sysadmin rolü ile sınırlıdır. Varsayılan olarak sysadmin rolü Windows BUILTIN\Administrators grubunun ve yerel yöneticinin grubunun tüm üyelerini içerir. DBCC komutu, veri koleksiyonu işlemi başarısız olursa başarısız olmaz.

Hataları Çözme

DBCC CHECKDB herhangi bir hata rapor ederse, REPAIR komutunu REPAIR seçeneklerinden biri ile çalıştırmak yerine veritabanını veritabanı yedeğinden geri yüklemenizi öneririz. Hiçbir yedek yoksa, onarım komutunu çalıştırmak rapor edilen hataları giderir. Kullanılacak onarım seçeneği, rapor edilen hatalar listesinin sonunda belirtilir. Ancak, hataları REPAIR_ALLOW_DATA_LOSS seçeneğini kullanarak düzeltmek bazı sayfaların, dolayısıyla bazı verilerin silinmesini gerektirebilir.

Bazı durumlarda, veritabanına geçerli olmayan veya sütunun veri türü açısından aralık dışında kalan veriler girilebilir. DBCC CHECKDB tüm sütun veri türleri için geçerli olmayan sütun değerlerini algılayabilir. Dolayısıyla daha önceki SQL Server sürümlerinden yükseltilmiş veritabanlarında DBCC CHECKDB komutunun DATA_PURITY seçeneği ile çalıştırılması daha önceden var olan sütun değeri hatalarını ortaya çıkarabilir. SQL Server bu hataları otomatik olarak onaramadığından, sütun değerinin el ile güncelleştirilmesi gerekir. CHECKDB bu tür bir hatayı algılarsa, CHECKDB bir uyarı, 2570 numaralı hatayı ve el ile düzeltilmesi için hatadan etkilenen satırı belirleyecek bilgileri döndürür.

Onarım, kullanıcının yapılan değişiklikleri geri alabilmesi için bir kullanıcı işlemi altında gerçekleştirilebilir. Onarımlar geri alınırsa, veritabanı hala hatalar içeriyor olur ve bir yedekten geri yüklenmesi gerekir. Onarımlar tamamlandıktan sonra veritabanını yedekleyin.

Hataları Veritabanı Acil Modunda Düzeltme

Bir veritabanı ALTER DATABASE deyimi kullanılarak acil moda ayarlandığında, DBCC CHECKDB, REPAIR_ALLOW_DATA_LOSS seçeneği belirtilirse veritabanında bazı özel onarımlar gerçekleştirebilir. Bu onarımlar normalde kurtarılamaz veritabanlarının fiziksel olarak tutarlı bir durumda yeniden çevrimiçine alınmasına izin verebilir. Bu onarımların yalnızca son çare olarak ve veritabanı bir yedekten geri yüklenemediğinde yapılması gerekir. Veritabanı acil moda ayarlandığında READ_ONLY olarak işaretlenir, günlüğe yazma devre dışı bırakılır ve erişim sysadmin sabit sunucu rolü üyeleri ile sınırlanır.

[!NOT]

DBCC CHECKDB komutunu acil modda bir kullanıcı işlemi içinde çalıştıramaz ve çalıştırmadan sonra işlemi geri alamazsınız.

Veritabanı acil modda olduğunda ve DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS yan tümcesi ile çalıştırıldığında, aşağıdaki işlemler yapılır:

  • DBCC CHECKDB, G/Ç veya sağlama toplamı hataları nedeniyle erişilemez olarak işaretlenmiş sayfaları, hatalar oluşmamış gibi kullanır. Bunun yapılması veritabanından veri kurtarılması olasılığını artırır.

  • DBCC CHECKDB veritabanını normal günlüğe dayalı kurtarma teknikleriyle kurtarmaya çalışır.

  • İşlem günlüğünde bozulma nedeniyle veritabanı kurtarma başarılı olmazsa, işlem günlüğü yeniden oluşturulur. İşlem günlüğünün yeniden oluşturulması işlem tutarlılığının yitirilmesiyle sonuçlanabilir.

DBCC CHECKDB komutu başarılı olursa, veritabanı fiziksel olarak tutarlı bir durumda olur ve veritabanı durumu ONLINE olarak ayarlanır. Ancak veritabanı bir veya daha fazla işlem tutarsızlığı içerebilir. İş mantığındaki kusurları belirlemek içinDBCC CHECKCONSTRAINTS komutunu çalıştırmanızı ve veritabanını hemen yedeklemenizi öneririz.

DBCC CHECKDB komutu başarısız olursa, veritabanı onarılamaz.

DBCC CHECKDB Komutunu Çoğaltılmış Veritabanlarında REPAIR_ALLOW_DATA_LOSS ile Çalıştırma

DBCC CHECKDB komutunu REPAIR_ALLOW_DATA_LOSS seçeneği ile çalıştırmak, kullanıcı veritabanlarını (yayımlama ve abonelik veritabanları) ve çoğaltmanın kullandığı dağıtım veritabanını etkileyebilir. Yayımlama ve abonelik veritabanları yayınlanmış tabloları ve çoğaltma meta veri tablolarını içerir. Veritabanlarında oluşabilecek aşağıdaki olası sorunların bilincinde olun:

  • Yayımlanmış tablolar. CHECKDB işlemi tarafından bozuk kullanıcı verilerini onarmak için gerçekleştirilen işlemler çoğaltılamayabilir:

    • Birleştirme çoğaltması yayımlanmış tablolardaki değişiklikleri izlemek için tetikler kullanır. CHECKDB işlemi tarafından satır eklenir, güncelleştirilir veya silinirse tetikler çalışmaz; bu yüzden değişiklik çoğaltılmaz.

    • İşlem çoğaltması yayımlanmış tablolardaki değişiklikleri izlemek için işlem günlüğünü kullanır. Günlük Okuyucu Aracısı daha sonra bu değişiklikleri dağıtım veritabanına taşır. Bazı DBCC onarımları, günlüğe yazılsa bile Günlük Okuyucu Aracısı tarafından çoğaltılamaz. Örneğin, bir veri sayfasının yeri CHECKDB işlemi tarafından bırakılamazsa, Günlük Okuyucu Aracısı bunu bir DELETE deyimine çevirmez; dolayısıyla değişiklik çoğaltılmaz.

  • Çoğaltma meta veri tabloları. Bozuk çoğaltma meta verisi tablolarını onarmak için CHECKDB işlemi tarafından gerçekleştirilen eylemler çoğaltmayı kaldırmayı ve yeniden yapılandırmayı gerektirir.

DBCC CHECKDB komutunu bir kullanıcı veya dağıtım veritabanı üzerinde REPAIR_ALLOW_DATA_LOSS seçeneği ile çalıştırmanız gerekiyorsa:

  1. Sistemi devreden çıkarın: Veritabanı ve çoğaltma topolojisindeki tüm diğer veritabanlarındaki etkinlikleri durdurun ve sonra tüm düğümleri eşitlemeye çalışın. Daha fazla bilgi için, bkz. Quiesce çoğaltma topolojisini (çoğaltma Transact-sql programlama).

  2. DBCC CHECKDB komutunu çalıştırın.

  3. DBCC CHECKDB raporu dağıtım veritabanındaki herhangi bir tablo veya bir kullanıcı veritabanındaki herhangi bir meta veri tablosu onarımları içeriyorsa, çoğaltmayı kaldırıp yeniden yapılandırın. Daha fazla bilgi için, bkz. Yayımlama ve dağıtım devre dışı bırakma.

  4. DBCC CHECKDB raporu çoğaltılan herhangi bir tablo için onarımlar içeriyorsa, yayım ve abonelik veritabanlarındaki veriler arasında farklar olup olmadığını belirlemek için veri doğrulama gerçekleştirin.

Sonuç Kümeleri

DBCC CHECKDB aşağıdaki sonuç kümesini döndürür. Değerler, ESTIMATEONLY, PHYSICAL_ONLY veya NO_INFOMSGS seçeneklerinin belirtildiği durumlar dışında değişkenlik gösterir:

DBCC results for 'model'.

Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.

Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.

Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.

Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.

There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.

There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.

There are 195 rows in 3 pages for object 'sysallocunits'.

There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.

There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.

There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.

There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.

There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB, NO_INFOMSGS belirtildiğinde aşağıdaki sonuç kümesini (ileti) döndürür:

The command(s) completed successfully.

DBCC CHECKDB, PHYSICAL_ONLY belirtildiğinde aşağıdaki sonuç kümesini döndürür:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB, ESTIMATEONLY belirtildiğinde aşağıdaki sonuç kümesini döndürür.

Estimated TEMPDB space needed for CHECKALLOC (KB)

-------------------------------------------------

13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)

--------------------------------------------------

57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

İzinler

sysadmin sabit sunucu rolüne veya db_owner sabit veritabanı rolüne üye olmayı gerektirir.

Örnekler

A.Hem geçerli hem başka bir veritabanını denetleme

Aşağıdaki örnek DBCC CHECKDB komutunu geçerli ve AdventureWorks2012 veritabanı için çalıştırmaktadır.

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2012 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2012, NOINDEX);
GO

B.Geçerli veritabanını denetleme, bilgi iletilerini kapatma

Aşağıdaki örnek, geçerli veritabanını denetlemekte ve tüm bilgi iletilerini kapatmaktadır.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Ayrıca bkz.

Başvuru

DBCC (Transact-sql)

sp_helpdb (Transact-sql)

Sistem tabloları (Transact-sql)

Kavramlar

Veritabanı Snapshot (Transact-sql) seyrek dosya boyutunu görüntülemek