Aracılığıyla paylaş

DBCC CHECKDB (Transact-SQL)

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen Örneği

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 çalıştırır.

  • Veritabanındaki her tabloda ve görünümde DBCC CHECKTABLE çalıştırır.

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

  • Veritabanındaki dizine alınan her görünümün içeriğini doğrular.

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

  • Veritabanındaki Hizmet Aracısı verilerini doğrular.

Bu, DBCC CHECKALLOC, DBCC CHECKTABLEveya DBCC CHECKCATALOG komutlarının DBCC CHECKDB'dan ayrı olarak çalıştırılması gerekmeyecek 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.

DBCC CHECKDB bellek için iyileştirilmiş tablolar içeren veritabanlarında desteklenir, ancak doğrulama yalnızca disk tabanlı tablolarda gerçekleşir. Ancak, veritabanı yedekleme ve kurtarmanın bir parçası olarak, bellek için iyileştirilmiş dosya gruplarındaki dosyalar için CHECKSUM doğrulama yapılır.

DbCC onarım seçenekleri bellek için iyileştirilmiş tablolar için kullanılamadığından veritabanlarınızı düzenli olarak yedeklemeli ve yedeklemeleri test etmelisiniz. Bellek için iyileştirilmiş bir tabloda veri bütünlüğü sorunları oluşursa, bilinen son iyi yedeklemeden geri yüklemeniz gerekir.

Transact-SQL söz dizimi 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 } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Bağımsız değişken

database_name | database_id | 0

Bütünlük denetimlerinin çalıştırıldığı veritabanının adı veya kimliği. Belirtilmezse veya 0 belirtilirse geçerli veritabanı kullanılır. Veritabanı adları tanımlayıcılarının kurallarına uymalıdır.

NOINDEX

Kullanıcı tabloları için kümelenmemiş dizinlerin yoğun denetimlerinin gerçekleştirilemdiğini belirtir. Bu seçim, genel yürütme süresini azaltır. NOINDEX sistem tablolarını etkilemez çünkü bütünlük denetimleri her zaman sistem tablosu dizinlerinde gerçekleştirilir.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

DBCC CHECKDB bulunan hataları onardığını belirtir. REPAIR_* seçeneklerini yalnızca son çare olarak kullanın. Aşağıdaki onarım seçeneklerinden birini kullanabilmek için belirtilen veritabanının tek kullanıcılı modda olması gerekir.

  • REPAIR_ALLOW_DATA_LOSS

    Bildirilen tüm hataları onarmaya çalışır. Bu onarımlar veri kaybına neden olabilir.

    Uyarı

    REPAIR_ALLOW_DATA_LOSS seçeneği, bilinen son iyi yedeklemeden geri yükleme işlemine kıyasla daha fazla veri kaybına neden olabilir. bkz. REPAIR_ALLOW_DATA_LOSS ile Veri kaybı uyarısı

    Microsoft, DBCC CHECKDBtarafından bildirilen hatalardan kurtarmak için her zaman bilinen son iyi yedeklemeden birincil yöntem olarak bir kullanıcı geri yüklemesini önerir. REPAIR_ALLOW_DATA_LOSS seçeneği, bilinen iyi bir yedeklemeden geri yükleme için alternatif değildir. Yalnızca yedekten geri yükleme mümkün değilse kullanılması önerilen acil durum son çare seçeneğidir.

    Yalnızca REPAIR_ALLOW_DATA_LOSS seçeneği kullanılarak onarılabilen bazı hatalar, hataları temizlemek için bir satır, sayfa veya sayfa dizisinin serbest bırakılmasını içerebilir. Serbest bırakılan veriler artık kullanıcı için erişilebilir veya kurtarılamaz ve serbest bırakılan verilerin tam içeriği belirlenemez. Bu nedenle, yabancı anahtar kısıtlamaları bu onarım işleminin bir parçası olarak denetlenmediğinden veya korunmadığından, herhangi bir satır veya sayfa serbest bırakıldıktan sonra bilgi tutarlılığı doğru olmayabilir. Kullanıcı, REPAIR_ALLOW_DATA_LOSS seçeneğini kullandıktan sonra veritabanının bilgi tutarlılığını (DBCC CHECKCONSTRAINTSkullanarak) incelemelidir.

    Onarımı gerçekleştirmeden önce, bu veritabanına ait dosyaların fiziksel kopyalarını oluşturmanız gerekir. Bu, birincil veri dosyasını (.mdf), tüm ikincil veri dosyalarını (.ndf), tüm işlem günlüğü dosyalarını (.ldf) ve tam metin katalogları, dosya akışı klasörleri, bellek için iyileştirilmiş veriler vb. dahil olmak üzere veritabanını oluşturan diğer kapsayıcıları içerir.

    Onarımı gerçekleştirmeden önce veritabanının durumunu EMERGENCY moduna değiştirmeyi ve kritik tablolardan mümkün olduğunca fazla bilgi ayıklamayı ve bu verileri kaydetmeyi deneyin.

  • REPAIR_FAST

    Yalnızca geriye dönük uyumluluk için söz dizimlerini korur. Hiçbir onarım eylemi gerçekleştirilmez.

  • REPAIR_REBUILD

    Veri kaybı olasılığı olmayan onarımlar gerçekleştirir. Bu seçenek, kümelenmemiş dizinlerdeki eksik satırları onarma gibi hızlı onarımları ve dizini yeniden derleme gibi daha fazla zaman alan onarımı içerebilir.

    Bu bağımsız değişken FILESTREAM verileriyle ilgili hataları onarmaz.

Önemli

REPAIR_* seçeneklerinden herhangi biriyle DBCC CHECKDB tamamen günlüğe kaydedildiğinden ve kurtarılabilir olduğundan, Microsoft her zaman kullanıcının işlemin sonuçlarını kabul etmek istediğini onay edebilmesi için bir işlem içindeki REPAIR_* seçenekleriyle (komutu çalıştırmadan önce BEGIN TRANSACTION yürüt) DBCC CHECKDB kullanmasını önerir. Daha sonra kullanıcı, onarım işlemi tarafından yapılan tüm işleri işlemek için COMMIT TRANSACTION yürütebilir. Kullanıcı işlemin sonuçlarını kabul etmek istemezse, onarım işlemlerinin etkilerini geri almak için bir ROLLBACK TRANSACTION yürütebilir.

Hataları onarmak için yedekten geri yüklemenizi öneririz. Onarım işlemleri, tablolarda veya tablolar arasında mevcut olabilecek kısıtlamaları dikkate almaz. Belirtilen tablo bir veya daha fazla kısıtlamaya dahilse, bir onarım işleminden sonra DBCC CHECKCONSTRAINTS çalıştırmanızı öneririz. REPAIR_*kullanmanız gerekiyorsa, kullanılacak onarım düzeyini bulmak için DBCC CHECKDB bir onarım seçeneği olmadan çalıştırın. REPAIR_ALLOW_DATA_LOSS düzeyini kullanıyorsanız, bu seçenekle DBCC CHECKDB çalıştırmadan önce veritabanını yedeklemenizi öneririz.

ALL_ERRORMSGS

Nesne başına bildirilen tüm hataları görüntüler. Tüm hata iletileri varsayılan olarak görüntülenir. Bu seçeneği belirtmenin veya atlamanın hiçbir etkisi yoktur. Hata iletileri, tempdb veritabanıoluşturulan iletiler dışında nesne kimliğine göre sıralanır.

EXTENDED_LOGICAL_CHECKS

Uyumluluk düzeyi SQL Server 2008'de (10.0.x) sunulan 100 ise, bu seçenek dizinlenmiş görünümde, XML dizinlerinde ve uzamsal dizinlerde mantıksal tutarlılık denetimleri gerçekleştirir.

Daha fazla bilgi için bu makalenin devamında dizinlerde mantıksal tutarlılık denetimleri gerçekleştirme bakın.

NO_INFOMSGS

Tüm bilgilendirme iletilerini gizler.

TABLOCK

DBCC CHECKDB iç veritabanı anlık görüntüsü kullanmak yerine kilitleri almasına neden olur. Bu, veritabanında kısa vadeli özel (X) kilidi içerir. TABLOCK, DBCC CHECKDB yoğun yük altındaki bir veritabanında daha hızlı çalışmasına neden olur, ancak DBCC CHECKDB çalışırken veritabanında kullanılabilen eşzamanlılığı azaltır.

Önemli

TABLOCK gerçekleştirilen denetimleri sınırlar; DBCC CHECKCATALOG veritabanında çalıştırılmıyor ve Hizmet Aracısı verileri doğrulanmıyor.

TAHMINE GÖRE

Belirtilen diğer tüm seçeneklerle DBCC CHECKDB çalıştırmak için gereken tahmini tempdb alanı miktarını görüntüler. Gerçek veritabanı denetimi gerçekleştirilmiyor.

PHYSICAL_ONLY

Denetimi, sayfanın ve kayıt üst bilgilerinin fiziksel yapısının bütünlüğüyle ve veritabanının ayırma tutarlılığıyla sınırlar. Bu denetim, veritabanının fiziksel tutarlılığı için küçük bir ek yük denetimi sağlamak üzere tasarlanmıştır, ancak kullanıcının verilerini tehlikeye atabilecek bozuk sayfaları, sağlama toplamı hatalarını ve yaygın donanım hatalarını da algılayabilir.

DBCC CHECKDB tam çalıştırmasının tamamlanması önceki sürümlerden çok daha uzun sürebilir. Bu davranış şu nedenlerle oluşur:

  • Mantıksal denetimler daha kapsamlıdır.
  • Denetlenecek temel yapılardan bazıları daha karmaşıktır.
  • Yeni özellikleri içeren birçok yeni denetim kullanıma sunulmuştur.

Bu nedenle, PHYSICAL_ONLY seçeneğinin kullanılması büyük veritabanlarında DBCC CHECKDB için çok daha kısa bir çalışma süresine neden olabilir ve üretim sistemlerinde sık kullanım için önerilir. Yine de DBCC CHECKDB tam çalıştırmasının düzenli aralıklarla gerçekleştirilmesi önerilir. Bu çalıştırmaların sıklığı, tek tek işletmelere ve üretim ortamlarına özgü faktörlere bağlıdır.

Bu bağımsız değişken her zaman NO_INFOMSGS anlamına gelir ve onarım seçeneklerinden herhangi biriyle birlikte kullanılamaz.

Uyarı

PHYSICAL_ONLY belirtilmesi, DBCC CHECKDB FILESTREAM verilerinin tüm denetimlerini atlamasına neden olur.

DATA_PURITY

DBCC CHECKDB geçerli olmayan veya aralık dışında olan sütun değerlerinin veritabanını denetlemesine neden olur. Örneğin, DBCC CHECKDBdatetime veri türü için kabul edilebilir aralıktan büyük veya daha küçük tarih ve saat değerlerine sahip sütunları algılar; veya geçerli olmayan ölçek veya duyarlık değerlerine sahip ondalık veya yaklaşık sayısal veri türü sütunlarını.

Sütun-değer bütünlüğü denetimleri varsayılan olarak etkindir ve DATA_PURITY seçeneğini gerektirmez. SQL Server'ın önceki sürümlerinden yükseltilen veritabanları için, DBCC CHECKDB WITH DATA_PURITY veritabanında hatasız çalıştırılana kadar sütun-değer denetimleri varsayılan olarak etkinleştirilmez. Bundan sonra, DBCC CHECKDB varsayılan olarak sütun-değer bütünlüğünü denetler. CHECKDB sql server'ın önceki sürümlerinden veritabanı yükseltmesinden nasıl etkilenebileceği hakkında daha fazla bilgi için, bu makalenin devamında yer alan Açıklamalar bölümüne bakın.

Uyarı

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

Bu seçenek tarafından bildirilen doğrulama hataları DBCC onarım seçenekleri kullanılarak düzeltilemiyor. Bu hataları el ile düzeltme hakkında bilgi için bkz. MSSQLSERVER_2570.

MAXDOP

için geçerlidir: SQL Server 2014 (12.x) Service Pack 2 ve sonraki sürümleri

deyimi için sp_configuremax degree of parallelism yapılandırma seçeneğini geçersiz kılar. MAXDOP, sp_configureile yapılandırılan değeri aşabilir. MAXDOP Resource Governor ile yapılandırılan değeri aşarsa, SQL Server Veritabanı Altyapısı ALTER WORKLOAD GROUPbölümünde açıklanan Resource Governor MAXDOP değerini kullanır. max degree of parallelism yapılandırma seçeneğiyle kullanılan tüm anlam kuralları, MAXDOP sorgu ipucunu kullandığınızda geçerlidir. Daha fazla bilgi için bkz. Sunucu yapılandırması: en yüksek paralellik derecesi.

Uyarı

MAXDOP sıfır olarak ayarlanırsa SQL Server kullanılacak max degree of parallelism seçer.

Açıklamalar

DBCC CHECKDB devre dışı bırakılmış dizinleri incelemez. Devre dışı bırakılan dizinler hakkında daha fazla bilgi için bkz. dizinleri 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ştirmesi olmalıdır. Bayt sıralı kullanıcı tanımlı türlerin tutarlı seri hale getirilmemesi, DBCC CHECKDB çalıştırıldığında hata 2537'ye neden olur. Daha fazla bilgi için bkz. Oluşturma User-Defined Türleri - Gereksinimler.

Kaynak veritabanı yalnızca tek kullanıcı modunda değiştirilebilir olduğundan, DBCC CHECKDB komutu doğrudan üzerinde çalıştırılamaz. Ancak, DBCC CHECKDBana veritabanıyürütürse, kaynak veritabanında ikinci bir CHECKDB de dahili olarak çalıştırılır. Bu, DBCC CHECKDB ek sonuçlar döndürebileceği anlamına gelir. Hiçbir seçenek ayarlı olmadığında veya PHYSICAL_ONLY veya ESTIMATEONLY seçeneği ayarlandığında komut ek sonuç kümeleri döndürür.

SQL Server 2005 (9.x) Service Pack 2 ve sonraki sürümlerinde, DBCC CHECKDB yürütülmesi artık SQL Server örneğinin plan önbelleğini temizlemez. SQL Server 2005 (9.x) Service Pack 2'nin öncesinde, DBCC CHECKDB yürütülmesi plan önbelleğini temizler. Plan önbelleğinin temizlenmesi, sonraki tüm yürütme planlarının yeniden derlenmesine neden olur ve sorgu performansında ani, geçici bir düşüşe neden olabilir.

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şir:

  • Uyumluluk düzeyi en az 100 ise (SQL Server 2008'de (10.0.x) kullanıma sunulmuştur):

  • NOINDEX belirtilmediği sürece, DBCC CHECKDB tek bir tabloda ve tüm kümelenmemiş dizinlerinde hem fiziksel hem de mantıksal tutarlılık denetimleri gerçekleştirir. Ancak XML dizinlerinde uzamsal dizinler ve dizinlenmiş 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 görünümde, XML dizinlerinde ve uzamsal dizinlerde gerçekleştirilir ve burada bulunur. Varsayılan olarak, fiziksel tutarlılık denetimleri mantıksal tutarlılık denetimleri öncesinde gerçekleştirilir. NOINDEX de belirtilirse, yalnızca mantıksal denetimler gerçekleştirilir.

Bu mantıksal tutarlılık denetimleri, dizin nesnesinin iç dizin tablosunu başvurduğunu kullanıcı tablosuyla çapraz denetler. Satırları bulmak için iç ve kullanıcı tablolarının tam kesişimini gerçekleştirmek üzere bir iç sorgu oluşturulur. Bu sorguyu çalıştırmanın performans üzerinde önemli bir etkisi olabilir ve ilerleme durumu izlenemez. Bu nedenle, WITH EXTENDED_LOGICAL_CHECKS yalnızca fiziksel bozulmayla ilgili olmayan dizin sorunlarından şüpheleniyorsanız veya sayfa düzeyi sağlama toplamları kapatılmışsa ve sütun düzeyinde donanım bozulmasından şüpheleniyorsanız belirtmeniz önerilir.

  • Dizin filtrelenmiş bir dizinse, DBCC CHECKDB dizin girdilerinin filtre koşulunu karşılayıp karşılamadığını doğrulamak için tutarlılık denetimleri gerçekleştirir.

  • NOINDEX belirtilmediği sürece uyumluluk düzeyi 90 veya daha azsa, DBCC CHECKDB tek bir tabloda veya dizinlenmiş görünümde ve tüm onun kümelenmemiş ve XML dizinlerinde hem fiziksel hem de mantıksal tutarlılık denetimleri gerçekleştirir. Uzamsal dizinler desteklenmez.

  • SQL Server 2016 (13.x) ve sonraki sürümlerinde, pahalı ifade değerlendirmelerinden kaçınmak için kalıcı hesaplanan sütunlar, UDT sütunları ve filtrelenmiş dizinler üzerinde ek denetimler varsayılan olarak çalışmaz. Bu değişiklik, bu nesneleri içeren veritabanlarında CHECKDB süresini büyük ölçüde azaltır. Ancak, bu nesnelerin fiziksel tutarlılık denetimi her zaman tamamlanır. Yalnızca EXTENDED_LOGICAL_CHECKS seçenek belirtildiğinde, EXTENDED_LOGICAL_CHECKS seçeneğinin (dizinli görünüm, XML dizinleri ve uzamsal dizinler) parçası olarak zaten mevcut olan mantıksal denetimlere ek olarak ifade değerlendirmeleri gerçekleştirilir.

Veritabanının uyumluluk düzeyini öğrenme

  • Veritabanı uyumluluk düzeyini görüntüleme veya değiştirme

İç veritabanı anlık görüntüsü

DBCC CHECKDB bu denetimleri gerçekleştirmek için gereken işlem tutarlılığı için bir iç veritabanı anlık görüntüsü kullanır. Bu, bu komutlar yürütülürken engelleme ve eşzamanlılık sorunlarını önler. Daha fazla bilgi için dbcc veritabanı anlık görüntü Seyrek Dosyasının Boyutunu Görüntüleme ve DBCC iç veritabanı anlık görüntü kullanımı bölümüne bakın. Anlık görüntü oluşturulamazsa veya TABLOCK belirtilirse, DBCC CHECKDB gerekli tutarlılığı elde etmek için kilitleri alır. Bu durumda, ayırma denetimlerini gerçekleştirmek için özel veritabanı kilidi ve tablo denetimlerini gerçekleştirmek için paylaşılan tablo kilitleri gerekir.

DBCC CHECKDB bir iç veritabanı anlık görüntüsü oluşturulamıyorsa master veritabanında çalıştırıldığında başarısız olur.

tempdb üzerinde DBCC CHECKDB çalıştırmak herhangi bir ayırma veya katalog denetimi gerçekleştirmez ve tablo denetimleri gerçekleştirmek için paylaşılan tablo kilitleri almalıdır. Bunun nedeni, performans nedenleriyle veritabanı anlık görüntülerinin tempdbüzerinde kullanılamamasidir. Bu, gerekli işlem tutarlılığının alınamıyacağı anlamına gelir.

DBCC CHECKDB, SQL Server 2014'den başlayarak iç anlık görüntü veritabanı oluşturma

  1. DBCC CHECKDB bir iç anlık görüntü veritabanı oluşturur.

  2. İç anlık görüntü veritabanı fiziksel dosyalar kullanılarak oluşturulur. Örneğin , E:\Data\my_DB.ndfve E:\Data\my_DB.ldfE:\Data\my_DB.mdfüç dosyası olan database_id = 10 olan bir veritabanı için, iç anlık görüntü veritabanı E:\Data\my_DB.mdf_MSSQL_DBCC11 ve E:\Data\my_DB.ndf_MSSQL_DBCC11 dosyaları kullanılarak oluşturulur. Anlık görüntünün database_iddatabase_id + 1. Ayrıca, yeni dosyaların <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>adlandırma kuralı kullanılarak aynı klasörde oluşturulduğunu unutmayın. İşlem günlüğü için seyrek dosya oluşturulmaz.

  3. Yeni dosyalar, dosya sistemi düzeyinde seyrek dosyalar olarak işaretlenir. Yeni dosyalar tarafından kullanılan Disk Boyutu, DBCC CHECKDB komutu sırasında kaynak veritabanında ne kadar verinin güncelleştirildiği temelinde artar. Yeni dosyaların Boyutu, .mdf veya .ndf dosyasıyla aynıdır.

  4. Yeni dosyalar, DBCC CHECKDB işlemenin sonunda silinir. DBCC CHECKDB tarafından oluşturulan bu seyrek dosyaların "Kapatıldığında Sil" öznitelikleri ayarlanmıştır.

Uyarı

DBCC CHECKDB komutu devam ederken işletim sistemi beklenmeyen bir kapatmayla karşılaşırsa, bu dosyalar temizlenmez. Bunlar yer kaplar ve gelecekteki DBCC CHECKDB yürütmelerinde hatalara neden olabilir. Bu durumda, şu anda yürütülmekte olan bir DBCC CHECKDB komutu olmadığını onayladıktan sonra bu yeni dosyaları silebilirsiniz.

Yeni dosyalar, Windows Gezgini gibi sıradan dosya yardımcı programları kullanılarak görülebilir.

Not

SQL Server 2014'den (12.x) önce, iç anlık görüntü dosyalarını oluşturmak için dosya akışları olarak adlandırılmıştı. Adlandırılmış dosya akışları, :MSSQL_DBCC<database_id_of_snapshot>>filename.extension <biçimini kullandı. Adlandırılmış dosya akışları, Windows Gezgini gibi sıradan dosya yardımcı programları kullanılarak görünmez. Bu nedenle, SQL Server 2012 (11.x) ve önceki sürümlerinde, ReFSbiçimlendirilmiş bir birimde bulunan veritabanı dosyaları için DBCC CHECKDB komutunu çalıştırdığınızda 7926 ve 5030 hata iletileriyle karşılaşabilirsiniz. Bunun nedeni, dosya akışlarının Dayanıklı Dosya Sistemi (RefS)oluşturulamamadır.

FILESTREAM verilerini denetleme ve onarma

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

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

En iyi yöntemler

Üretim sistemlerinde sık kullanım için PHYSICAL_ONLY seçeneğini kullanmanızı öneririz. PHYSICAL_ONLY kullanmak, büyük veritabanlarında DBCC CHECKDB için çalışma süresini büyük ölçüde kısaltabilir. Ayrıca DBCC CHECKDB düzenli aralıklarla hiçbir seçenek olmadan çalıştırmanızı öneririz. Bu çalıştırmaları ne sıklıkta gerçekleştirmeniz gerektiği, tek tek işletmelere ve üretim ortamlarına bağlıdır.

Azure SQL Yönetilen Örneği'nin kullanılabilir depolama alanı, verilerin gerçekte ne kadarının kullanıldığına bakılmaksızın DBCC CHECKDBtarafından oluşturulan iç veritabanı anlık görüntü dosyasının tamamını barındırmalıdır. Bu durum, sql yönetilen örneğinizde yer olmaması nedeniyle çok büyük ama seyrek bir veritabanında (verilerin boyutu veritabanı dosya boyutundan çok daha küçük) DBCC CHECKDB yürütmenin başarısız olmasına neden olabilir. DBCC CHECKDB yürütme sırasında tüm kullanılabilir depolama alanını kullanırsa aşağıdaki hata iletisini alırsınız:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Nesneleri paralel olarak denetleme

Varsayılan olarak, DBCC CHECKDB nesneleri paralel olarak denetler. Paralellik derecesi sorgu işlemcisi tarafından otomatik olarak belirlenir. En yüksek paralellik derecesi aynı paralel sorgular gibi yapılandırılır. DBCC denetimi için kullanılabilen en fazla işlemci sayısını kısıtlamak için sp_configurekullanın. Daha fazla bilgi için bkz. Sunucu yapılandırması: en yüksek paralellik derecesi. Paralel denetim, İzleme Bayrağı 2528 kullanılarak devre dışı bırakılabilir. Daha fazla bilgi için bkz. İzleme Bayrakları.

Not

Bu özellik SQL Server'ın her sürümünde kullanılamaz. Daha fazla bilgi için Sürümleri ve SQL Server 2022desteklenen özelliklerinin RDBMS yönetilebilirliği bölümünde paralel tutarlılık denetimi bölümüne bakın.

DBCC hata iletilerini anlama

DBCC CHECKDB komutu tamamlandıktan sonra SQL Server hata günlüğüne bir ileti yazılır. DBCC komutu başarıyla yürütülürse, ileti başarılı olduğunu ve komutun çalıştırıldığını gösterir. DBCC komutu bir hata nedeniyle denetimi tamamlamadan önce durursa, ileti komutun sonlandırıldığını, durum değerini ve komutun çalıştırıldığı süreyi gösterir. Aşağıdaki tabloda iletiye dahil edilebilecek durum değerleri listelenmiştir ve açıklanmaktadır.

Devlet Açıklama
0 Hata numarası 8930 oluşturuldu. Bu, DBCC komutunu sonlandıran meta verilerde bozulma olduğunu gösterir.
1 Hata numarası 8967 oluşturuldu. bir iç DBCC hatası oluştu.
2 Acil durum modu veritabanı onarımı sırasında bir hata oluştu.
3 Bu, DBCC komutunu sonlandıran meta verilerde bozulma olduğunu gösterir.
4 Onay veya erişim ihlali algılandı.
5 DBCC komutunu sonlandıran bilinmeyen bir hata oluştu.

SQL Server, bir veritabanı için tutarlılık denetiminin çalıştırıldığı tarihi ve saati hatasız (veya "temiz" tutarlılık denetimi) kaydeder. Bu, last known clean checkolarak bilinir. Bir veritabanı ilk kez başlatıldığında, bu tarih EventLog'a (EventID-17573) yazılır ve hata günlüğü aşağıdaki biçimde olur:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Hata raporlama

SQL Server LOG dizininde, DBCC CHECKDB bir bozulma hatası algılandığında bir yığın dökümü (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) oluşturulur. sql server örneği için Özellik Kullanımı veri toplama ve Hata Raporlama özellikleri etkinleştirildiğinde, dosya otomatik olarak Microsoft'a iletilir. Toplanan veriler SQL Server işlevselliğini geliştirmek için kullanılır. Döküm dosyası, DBCC CHECKDB komutunun sonuçlarını ve ek tanılama çıkışını içerir. Erişim, SQL Server hizmet hesabı ve sysadmin rolünün üyeleriyle sınırlıdır. Varsayılan olarak sysadmin rolü, Windows BUILTIN\Administrators grubunun ve yerel yönetici grubunun tüm üyelerini içerir. Veri toplama işlemi başarısız olursa DBCC komutu başarısız olmaz.

Hataları düzeltme

DBCC CHECKDBtarafından herhangi bir hata bildirilirse, REPAIR_* seçeneklerden biriyle DBCC CHECKDB çalıştırmak yerine veritabanını veritabanı yedeğinden geri yüklemenizi öneririz. Yedekleme yoksa, onarım çalıştırılırken bildirilen hatalar düzeltilir. Kullanılacak onarım seçeneği, bildirilen hatalar listesinin sonunda belirtilir. Ancak, REPAIR_ALLOW_DATA_LOSS seçeneğini kullanarak hataları düzeltmek için bazı sayfaların ve dolayısıyla bazı verilerin silinmesi gerekebilir.

Bazı durumlarda, veritabanına sütunun veri türüne göre geçerli olmayan veya aralık dışında değerler girilebilir. DBCC CHECKDB tüm sütun veri türleri için geçerli olmayan sütun değerlerini algılayabilir. Bu nedenle, SQL Server'ın önceki sürümlerinden yükseltilen veritabanlarında DATA_PURITY seçeneğiyle DBCC CHECKDB çalıştırmak, önceden var olan sütun-değer hataları ortaya çıkabilir. SQL Server bu hataları otomatik olarak onaramadığından sütun değeri el ile güncelleştirilmelidir. CHECKDB böyle bir hata algılarsa, CHECKDB bir uyarı, hata numarası 2570 ve etkilenen satırı tanımlamak ve hatayı el ile düzeltmek için bilgiler döndürür.

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

Veritabanı acil durum modundaki hataları düzeltme

veritabanı ALTER DATABASE deyimi kullanılarak acil durum moduna ayarlandığında, DBCC CHECKDBREPAIR_ALLOW_DATA_LOSS seçeneği belirtilirse veritabanında bazı özel onarımlar gerçekleştirebilir. Bu onarımlar normalde kurtarılamayan veritabanlarının fiziksel olarak tutarlı bir durumda yeniden çevrimiçi olmasına olanak tanıyabilir. Bu onarımlar son çare olarak ve yalnızca veritabanını yedekten geri yükleyemediğinizde kullanılmalıdır. Veritabanı acil durum moduna ayarlandığında, veritabanı READ_ONLY olarak işaretlenir, günlük devre dışı bırakılır ve erişim sysadmin sabit sunucu rolünün üyeleriyle sınırlıdır.

Not

DBCC CHECKDB komutunu bir kullanıcı işleminin içinde acil durum modunda çalıştıramaz ve yürütmeden sonra işlemi geri alamazsınız.

Veritabanı acil durum modunda olduğunda ve REPAIR_ALLOW_DATA_LOSS yan tümcesiyle DBCC CHECKDB çalıştırıldığında aşağıdaki eylemler yapılır:

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

  • DBCC CHECKDB, normal günlük tabanlı kurtarma tekniklerini kullanarak veritabanını kurtarmayı dener.

  • veritabanı kurtarma işlemi işlem günlüğü bozulması nedeniyle başarısız olursa, işlem günlüğü yeniden oluşturulur. İşlem günlüğünün yeniden oluşturulması işlem tutarlılığının kaybolmasına neden olabilir.

Uyarı

REPAIR_ALLOW_DATA_LOSS seçeneği, bilinen son iyi yedeklemeden geri yükleme işlemine kıyasla daha fazla veri kaybına neden olabilir. bkz. REPAIR_ALLOW_DATA_LOSS ile Veri kaybı uyarısı

DBCC CHECKDB komutu başarılı olursa, veritabanı fiziksel olarak tutarlı bir durumdadır ve veritabanı durumu ÇEVRİmİÇİ olarak ayarlanır. Ancak, veritabanı bir veya daha fazla işlem tutarsızlığı içerebilir. tüm iş mantığı açıklarını belirlemek ve veritabanını hemen yedeklemek için DBCC CHECKCONSTRAINTS çalıştırmanızı öneririz.

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

REPAIR_ALLOW_DATA_LOSS ile veri kaybı uyarısı

REPAIR_ALLOW_DATA_LOSS seçeneği SQL Server'ın desteklenen bir özelliğidir. Ancak, veritabanını fiziksel olarak tutarlı bir duruma getirmek için her zaman en iyi seçenek olmayabilir. Başarılı olursa, REPAIR_ALLOW_DATA_LOSS seçeneği veri kaybına neden olabilir.

Aslında, bir kullanıcının veritabanını bilinen son iyi yedeklemeden geri yüklemesinden daha fazla veri kaybına neden olabilir. Microsoft, DBCC CHECKDBtarafından bildirilen hatalardan kurtarmak için her zaman bilinen son iyi yedeklemeden birincil yöntem olarak bir kullanıcı geri yüklemesini önerir.

REPAIR_ALLOW_DATA_LOSS seçeneği, bilinen iyi bir yedeklemeden geri yükleme için alternatif . Yalnızca yedeklemeden geri yükleme mümkün değilse kullanılması önerilen acil durum son çare seçeneğidir.

Günlüğü yeniden derledikten sonra tam ACID garantisi yoktur.

Günlüğü yeniden derledikten sonra DBCC CHECKDB otomatik olarak gerçekleştirilir ve hem raporlar hem de fiziksel tutarlılık sorunlarını giderir.

Mantıksal veri tutarlılığı ve iş mantığı tarafından zorlanan kısıtlamalar el ile doğrulanmalıdır.

İşlem günlüğü boyutu varsayılan boyutuna bırakılır ve el ile son boyutuna geri ayarlanmalıdır.

Çoğaltılan veritabanlarında DBCC CHECKDB'REPAIR_ALLOW_DATA_LOSS çalıştırma

DBCC CHECKDB komutunun REPAIR_ALLOW_DATA_LOSS seçeneğiyle çalıştırılması, kullanıcı veritabanlarını (yayın ve abonelik veritabanları) ve çoğaltma tarafından kullanılan dağıtım veritabanını etkileyebilir. Yayın ve abonelik veritabanları, yayımlanan tabloları ve çoğaltma meta verileri tablolarını içerir. Bu veritabanlarında aşağıdaki olası sorunlara dikkat edin:

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

  • Birleştirme çoğaltması, yayımlanan tablolardaki değişiklikleri izlemek için tetikleyicileri kullanır. satırlar CHECKDB işlemi tarafından eklenir, güncelleştirilir veya silinirse tetikleyiciler tetiklenmez; bu nedenle, değişiklik çoğaltılamaz.

  • İşlem çoğaltması, yayımlanan tablolardaki değişiklikleri izlemek için işlem günlüğünü kullanır. Ardından Günlük Okuyucu Aracısı bu değişiklikleri dağıtım veritabanına taşır. Bazı DBCC onarımları günlüğe kaydedilmiş olsa da Günlük Okuyucu Aracısı tarafından çoğaltılamaz. Örneğin, bir veri sayfası CHECKDB işlemi tarafından serbest bırakılırsa, Günlük Okuyucu Aracısı bu ayırmayı delete deyimine çevirmez; bu nedenle, değişiklik çoğaltılamaz.

  • Çoğaltma meta veri tabloları. bozuk çoğaltma meta verileri tablolarını onarmak için CHECKDB işlemi tarafından gerçekleştirilen eylemler, çoğaltmanın kaldırılmasını ve yeniden yapılandırılmasını gerektirir.

DBCC CHECKDB komutunu bir kullanıcı veritabanında veya dağıtım veritabanında REPAIR_ALLOW_DATA_LOSS seçeneğiyle çalıştırmanız gerekiyorsa:

  1. Sistemi sessize al: Çoğaltma topolojisindeki veritabanında ve diğer tüm veritabanlarında etkinliği durdurun ve ardından tüm düğümleri eşitlemeyi deneyin. Daha fazla bilgi için bkz. Bir Çoğaltma Topolojisini Sessize Alma (Çoğaltma Transact-SQL Programlama) .

  2. DBCC CHECKDByürüt.

  3. DBCC CHECKDB raporu dağıtım veritabanındaki tabloların onarımlarını veya kullanıcı veritabanındaki çoğaltma meta verileri tablolarını içeriyorsa, çoğaltmayı kaldırın ve 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 tablolar için onarımlar içeriyorsa, yayındaki verilerle abonelik veritabanları arasındaki farkların olup olmadığını belirlemek için veri doğrulama gerçekleştirin.

Sonuç kümesi

DBCC CHECKDB aşağıdaki sonuç kümesini döndürür. değerler, ESTIMATEONLY, PHYSICAL_ONLYveya NO_INFOMSGS seçeneklerinin belirtilmemiş olduğu durumlar dışında değişebilir:

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 üyelik gerektirir.

Örnekler

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

Aşağıdaki örnek, geçerli veritabanı ve AdventureWorks2022 veritabanı için DBCC CHECKDB yürütür.

-- Check the current database.
DBCC CHECKDB;
GO

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

B. Geçerli veritabanını denetle, bilgilendiren iletileri gizle

Aşağıdaki örnek geçerli veritabanını denetler ve tüm bilgilendirme iletilerini gizler.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

İlgili içerik