DBCC CHECKDB (Transact-SQL)

Článek
03/05/2025

platí pro:SQL Server Azure SQL Database azure SQL Managed Instance

Zkontroluje logickou a fyzickou integritu všech objektů v zadané databázi provedením následujících operací:

Spustí DBCC CHECKALLOC v databázi.
Spouští DBCC CHECKTABLE v každé tabulce a zobrazení v databázi.
Spustí DBCC CHECKCATALOG databáze.
Ověří obsah každého indexovaného zobrazení v databázi.
Ověřuje konzistenci na úrovni propojení mezi metadaty tabulek a adresáři systému souborů a soubory při ukládání varbinary(max) dat v systému souborů pomocí FILESTREAM.
Ověří data služby Service Broker v databázi.

To znamená, že příkazy DBCC CHECKALLOC, DBCC CHECKTABLEnebo DBCC CHECKCATALOG nemusí být spouštěné odděleně od DBCC CHECKDB. Podrobnější informace o kontrolách, které tyto příkazy provádějí, najdete v popisu těchto příkazů.

DBCC CHECKDB se podporuje v databázích, které obsahují tabulky optimalizované pro paměť, ale ověřování probíhá pouze u tabulek založených na disku. V rámci zálohování a obnovení databáze se ale provádí ověřování CHECKSUM pro soubory v souborech optimalizovaných pro paměť.

Vzhledem k tomu, že možnosti opravy DBCC nejsou dostupné pro tabulky optimalizované pro paměť, musíte databáze pravidelně zálohovat a testovat zálohy. Pokud v tabulce optimalizované pro paměť dochází k problémům s integritou dat, musíte provést obnovení z poslední známé dobré zálohy.

Transact-SQL konvence syntaxe

Syntax

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 ]
        }
    ]
]

Argumenty

database_name | database_id | 0

Název nebo ID databáze, pro kterou se mají spouštět kontroly integrity. Pokud není zadána nebo pokud je zadána hodnota 0, použije se aktuální databáze. Názvy databází musí splňovat pravidla pro identifikátory .

NOINDEX

Určuje, že se neprovedou náročné kontroly neclusterovaných indexů pro tabulky uživatelů. Tato volba snižuje celkovou dobu provádění. NOINDEX nemá vliv na systémové tabulky, protože kontroly integrity se vždy provádějí na indexech systémových tabulek.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Určuje, že DBCC CHECKDB opraví nalezené chyby. Jako poslední možnost použijte možnosti REPAIR_*. Zadaná databáze musí být v režimu jednoho uživatele, aby bylo možné použít jednu z následujících možností opravy.

REPAIR_ALLOW_DATA_LOSS

Pokusí se opravit všechny nahlášené chyby. Tyto opravy můžou způsobit ztrátu dat.

Varování

Možnost REPAIR_ALLOW_DATA_LOSS může způsobit větší ztrátu dat, než když obnovíte z poslední známé dobré zálohy. Viz upozornění na ztrátu dat s REPAIR_ALLOW_DATA_LOSS

Microsoft vždy doporučuje obnovení uživatele z poslední známé dobré zálohy jako primární metodu pro zotavení z chyb hlášených DBCC CHECKDB. Možnost REPAIR_ALLOW_DATA_LOSS není alternativou pro obnovení ze známé dobré zálohy. Jedná se o nouzový poslední možností, která se doporučuje použít jenom v případě, že obnovení ze zálohy není možné.

Některé chyby, které je možné opravit pouze pomocí možnosti REPAIR_ALLOW_DATA_LOSS, můžou zahrnovat zrušení přidělení řádku, stránky nebo řady stránek, aby se chyby vymazaly. Všechna uvolněná data už nejsou pro uživatele přístupná ani obnovitelná a přesný obsah uvolněných dat se nedá určit. Proto nemusí být referenční integrita po zrušení přidělení řádků nebo stránek přesná, protože omezení cizího klíče nejsou v rámci této operace opravy kontrolována ani udržována. Po použití možnosti REPAIR_ALLOW_DATA_LOSS musí uživatel zkontrolovat referenční integritu své databáze (pomocí DBCC CHECKCONSTRAINTS).

Před provedením opravy musíte vytvořit fyzické kopie souborů, které patří do této databáze. To zahrnuje primární datový soubor (.mdf), všechny sekundární datové soubory (.ndf), všechny soubory transakčních protokolů (.ldf) a další kontejnery, které tvoří databázi, včetně úplných textových katalogů, složek datových proudů souborů, dat optimalizovaných pro paměť atd.

Před provedením opravy zvažte změnu stavu databáze na EMERGENCY režim a pokuste se extrahovat co nejvíce informací z kritických tabulek a uložit tato data.
REPAIR_FAST

Udržuje syntaxi pouze pro zpětnou kompatibilitu. Neprovádí se žádné akce opravy.
REPAIR_REBUILD

Provádí opravy, které nemají možnost ztráty dat. Tato možnost může zahrnovat rychlé opravy, například opravu chybějících řádků v neclusterovaných indexech a časově náročné opravy, například opětovné sestavení indexu.

Tento argument neopravuje chyby týkající se dat FILESTREAM.

Důležitý

Vzhledem k tomu, že DBCC CHECKDB s některou z možností REPAIR_* jsou zcela zaprotokolovány a obnovitelné, společnost Microsoft vždy doporučuje, aby uživatel používal DBCC CHECKDB s libovolnými možnostmi REPAIR_* v rámci transakce (před spuštěním příkazu spusťte BEGIN TRANSACTION), aby uživatel mohl potvrdit, že chce přijmout výsledky operace. Uživatel pak může spustit COMMIT TRANSACTION k potvrzení všech prací provedených operací opravy. Pokud uživatel nechce přijmout výsledky operace, může spustit ROLLBACK TRANSACTION vrátit zpět účinky operací opravy.

Pokud chcete opravit chyby, doporučujeme provést obnovení ze zálohy. Operace oprav nebere v úvahu žádná omezení, která by mohla existovat u tabulek nebo mezi tabulkami. Pokud je zadaná tabulka součástí jednoho nebo více omezení, doporučujeme spustit DBCC CHECKCONSTRAINTS po operaci opravy. Pokud je nutné použít REPAIR_*, spusťte DBCC CHECKDB bez možnosti opravy najít úroveň opravy, kterou chcete použít. Pokud používáte úroveň REPAIR_ALLOW_DATA_LOSS, doporučujeme před spuštěním DBCC CHECKDB pomocí této možnosti zálohovat databázi.

ALL_ERRORMSGS

Zobrazí všechny nahlášené chyby na objekt. Ve výchozím nastavení se zobrazí všechny chybové zprávy. Zadání nebo vynechání této možnosti nemá žádný vliv. Chybové zprávy jsou seřazeny podle ID objektu, s výjimkou těchto zpráv vygenerovaných z databáze databáze tempdb.

EXTENDED_LOGICAL_CHECKS

Pokud je úroveň kompatibility 100, zavedená v SYSTÉMU SQL Server 2008 (10.0.x), tato možnost provádí logické kontroly konzistence u indexovaného zobrazení, indexů XML a prostorových indexů, kde existují.

Další informace najdete v tématu Provádění logických kontrol konzistence u indexů dále v tomto článku.

NO_INFOMSGS

Potlačí všechny informační zprávy.

TABLOCK

Způsobí, že DBCC CHECKDB získat zámky místo použití interního snímku databáze. To zahrnuje krátkodobý exkluzivní zámek (X) v databázi. TABLOCK způsobí rychlejší spuštění DBCC CHECKDB v databázi s velkým zatížením, ale snižuje souběžnost dostupnou v databázi při spuštění DBCC CHECKDB.

Důležitý

TABLOCK omezuje provedené kontroly; DBCC CHECKCATALOG se v databázi nespustí a data Service Brokeru se neověřují.

ESTIMATEONLY

Zobrazí odhadovanou velikost tempdb místa potřebného ke spuštění DBCC CHECKDB se všemi ostatními zadanými možnostmi. Skutečná kontrola databáze se neprovádí.

PHYSICAL_ONLY

Omezuje kontrolu na integritu fyzické struktury záhlaví stránek a záznamů a konzistenci přidělení databáze. Tato kontrola je navržená tak, aby poskytovala malou režijní kontrolu fyzické konzistence databáze, ale může také detekovat roztržené stránky, selhání kontrolního součtu a běžné hardwarové chyby, které můžou ohrozit data uživatele.

Úplné spuštění DBCC CHECKDB může trvat výrazně déle než dřívější verze. K tomuto chování dochází, protože:

Logické kontroly jsou komplexnější.
Některé základní struktury, které se mají zkontrolovat, jsou složitější.
Zavedlo se mnoho nových kontrol, které zahrnují nové funkce.

Proto použití možnosti PHYSICAL_ONLY může způsobit mnohem kratší dobu běhu pro DBCC CHECKDB u velkých databází a doporučuje se pro časté použití v produkčních systémech. Přesto doporučujeme pravidelně provádět úplné spuštění DBCC CHECKDB. Frekvence těchto spuštění závisí na faktorech specifických pro jednotlivé firmy a produkční prostředí.

Tento argument vždy znamená NO_INFOMSGS a není povolen s žádnou z možností opravy.

Varování

Určení PHYSICAL_ONLY způsobí, že DBCC CHECKDB přeskočí všechny kontroly dat FILESTREAM.

DATA_PURITY

Způsobí, že DBCC CHECKDB zkontroluje, jestli databáze neobsahuje hodnoty sloupců, které nejsou platné nebo mimo rozsah. Například DBCC CHECKDB zjistí sloupce s hodnotami data a času, které jsou větší nebo menší než přijatelný rozsah pro datový typ datetime; nebo desetinných nebo přibližných číselných sloupcích s hodnotami měřítka nebo přesnosti, které nejsou platné.

Kontroly integrity hodnot sloupců jsou ve výchozím nastavení povolené a nevyžadují možnost DATA_PURITY. U databází upgradovaných ze starších verzí SQL Serveru nejsou ve výchozím nastavení povoleny kontroly hodnot sloupců, dokud DBCC CHECKDB WITH DATA_PURITY v databázi bez chyby. Potom DBCC CHECKDB ve výchozím nastavení kontroluje integritu hodnot sloupců. Další informace o tom, jak CHECKDB může být ovlivněn upgradem databáze ze starších verzí SQL Serveru, najdete v části Poznámky dále v tomto článku.

Varování

Pokud je zadán PHYSICAL_ONLY, neprovádí se kontroly integrity sloupců.

Chyby ověření hlášené touto možností nelze opravit pomocí možností opravy DBCC. Informace o ruční opravě těchto chyb najdete v tématu MSSQLSERVER_2570.

MAXDOP

platí pro: SQL Server 2014 (12.x) Service Pack 2 a novější verze

Přepíše možnost konfigurace max degree of parallelismsp_configure příkazu. MAXDOP může překročit hodnotu nakonfigurovanou pomocí sp_configure. Pokud MAXDOP překročí hodnotu nakonfigurovanou pro správce prostředků, použije databázový stroj SQL Serveru hodnotu MAXDOP správce prostředků popsanou v ALTER WORKLOAD GROUP. Všechna sémantická pravidla používaná s možností konfigurace max degree of parallelism se použijí při použití nápovědy k dotazu MAXDOP. Další informace naleznete v tématu Konfigurace serveru: maximální stupeň paralelismu.

Varování

Pokud je MAXDOP nastavena na nulu, sql Server zvolí max degree of parallelism použít.

Poznámky

DBCC CHECKDB nezkoumají zakázané indexy. Další informace o zakázaných indexech najdete v tématu Zakázání indexů a omezení.

Pokud je uživatelem definovaný typ označený jako seřazený bajt, musí existovat pouze jedna serializace uživatelem definovaného typu. Nemá konzistentní serializaci bajtů seřazených uživatelem definovaných typů způsobí chybu 2537 při spuštění DBCC CHECKDB. Další informace naleznete v tématu Vytváření typů User-Defined – požadavky.

Vzhledem k tomu, že databáze prostředků je možné upravit pouze v režimu jednoho uživatele, příkaz DBCC CHECKDB na něm nejde spustit přímo. Pokud se však DBCC CHECKDB spustí na hlavní databáze, druhý CHECKDB se také spustí interně v databázi prostředků. To znamená, že DBCC CHECKDB může vrátit další výsledky. Příkaz vrátí dodatečné sady výsledků, pokud nejsou nastaveny žádné možnosti, nebo pokud je nastavena možnost PHYSICAL_ONLY nebo ESTIMATEONLY.

V systému SQL Server 2005 (9.x) Service Pack 2 a novějších verzích se spuštěním DBCC CHECKDB již nevymaže mezipaměť plánu pro instanci SQL Serveru. Než sql Server 2005 (9.x) Service Pack 2 spustí DBCC CHECKDB vymaže mezipaměť plánu. Vymazání mezipaměti plánu způsobí rekompilace všech pozdějších plánů provádění a může způsobit náhlé dočasné snížení výkonu dotazů.

Provádění kontrol logické konzistence u indexů

Logická kontrola konzistence indexů se liší podle úrovně kompatibility databáze následujícím způsobem:

Pokud je úroveň kompatibility alespoň 100 (zavedená v SYSTÉMU SQL Server 2008 (10.0.x)):
Pokud není zadán NOINDEX, DBCC CHECKDB provádí kontroly fyzické i logické konzistence v jedné tabulce a ve všech neclusterovaných indexech. U indexů XML, prostorových indexů a indexovaných zobrazení se ale ve výchozím nastavení provádějí pouze kontroly fyzické konzistence.
Pokud je zadána WITH EXTENDED_LOGICAL_CHECKS, logické kontroly se provádějí v indexovaném zobrazení, indexech XML a prostorových indexech, kde existují. Ve výchozím nastavení se kontroly fyzické konzistence provádějí před kontrolami logické konzistence. Pokud je zadán také NOINDEX, provádějí se pouze logické kontroly.

Tyto logické konzistence kontrolují křížovou kontrolu interní tabulky indexu objektu indexu s uživatelskou tabulkou, na kterou odkazuje. Pro zjištění odsunutí řádků se vytvoří interní dotaz, který provede úplný průnik interních a uživatelských tabulek. Spuštění tohoto dotazu může mít významný vliv na výkon a jeho průběh nelze sledovat. Proto doporučujeme zadat WITH EXTENDED_LOGICAL_CHECKS pouze v případě, že máte podezření na problémy s indexem, které nesouvisejí s fyzickým poškozením, nebo pokud jsou kontrolní součty na úrovni stránky vypnuté a máte podezření na poškození hardwaru na úrovni sloupce.

Pokud je index filtrovaný index, DBCC CHECKDB provádí kontroly konzistence, aby ověřily, že položky indexu splňují predikát filtru.
Pokud je úroveň kompatibility 90 nebo menší, pokud není zadána NOINDEX, DBCC CHECKDB provádí kontroly fyzické i logické konzistence v jediné tabulce nebo indexovaném zobrazení a na všech jeho neclusterovaných a XML indexech. Prostorové indexy se nepodporují.
V SQL Serveru 2016 (13.x) a novějších verzích se ve výchozím nastavení nespustí další kontroly trvalých počítaných sloupců, sloupců UDT a filtrovaných indexů, aby nedocházelo k drahým vyhodnocením výrazů. Tato změna výrazně zkracuje dobu trvání CHECKDB vůči databázím obsahujícím tyto objekty. Kontrola fyzické konzistence těchto objektů je však vždy dokončena. Pouze pokud je zadána možnost EXTENDED_LOGICAL_CHECKS, provádí se kromě logických kontrol, které již existují jako součást možnosti EXTENDED_LOGICAL_CHECKS (indexované zobrazení, indexy XML a prostorové indexy).

Informace o úrovni kompatibility databáze

Zobrazení nebo změna úrovně kompatibility databáze

Snímek interní databáze

DBCC CHECKDB používá pro transakční konzistenci potřebnou k provedení těchto kontrol interní snímek databáze. To brání problémům s blokováním a souběžností při spuštění těchto příkazů. Další informace najdete v tématu Zobrazení velikosti zhuštěného souboru snímku databáze a použití interního snímku databáze DBCC v DBCC. Pokud není možné vytvořit snímek nebo je zadán TABLOCK, DBCC CHECKDB získá zámky pro získání požadované konzistence. V takovém případě se k provádění kontrol přidělení vyžaduje výhradní zámek databáze a k provádění kontrol tabulek se vyžadují zámky sdílených tabulek.

DBCC CHECKDB při spuštění v databázi master selže, pokud nejde vytvořit interní snímek databáze.

Spuštění DBCC CHECKDB proti tempdb neprovádí žádné kontroly přidělení ani katalogu a musí získat zámky sdílených tabulek, aby bylo možné provádět kontroly tabulek. Důvodem je to, že z důvodů výkonu nejsou snímky databáze na tempdbk dispozici . To znamená, že požadovanou transakční konzistenci nelze získat.

Jak DBCC CHECKDB vytvoří interní databázi snímků od SQL Serveru 2014

DBCC CHECKDB vytvoří interní databázi snímků.
Interní databáze snímků se vytváří pomocí fyzických souborů. Například pro databázi s database_id = 10, která má tři soubory E:\Data\my_DB.mdf, E:\Data\my_DB.ndfa E:\Data\my_DB.ldf, se vytvoří interní databáze snímků pomocí E:\Data\my_DB.mdf_MSSQL_DBCC11 a E:\Data\my_DB.ndf_MSSQL_DBCC11 souborů. database_id snímku je database_id + 1. Všimněte si také, že nové soubory jsou vytvořeny ve stejné složce pomocí zásad vytváření názvů <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Pro transakční protokol se nevytvoří žádný řídký soubor.
Nové soubory jsou označené jako zhuštěné soubory na úrovni systému souborů. Velikost na disku používaná novými soubory se zvyšuje v závislosti na tom, kolik dat se aktualizuje ve zdrojové databázi během příkazu DBCC CHECKDB. Velikost nových souborů je stejný soubor jako .mdf nebo .ndf soubor.
Nové soubory se odstraní na konci zpracování DBCC CHECKDB. Tyto řídké soubory vytvořené DBCC CHECKDB mají nastavené atributy Delete při zavření.

Varování

Pokud v průběhu příkazu DBCC CHECKDB dojde k neočekávanému vypnutí operačního systému, tyto soubory se nevyčistí. Zabírají místo a můžou potenciálně způsobit selhání budoucích DBCC CHECKDB spuštění. V takovém případě můžete tyto nové soubory odstranit poté, co potvrdíte, že aktuálně není spuštěn žádný příkaz DBCC CHECKDB.

Nové soubory jsou viditelné pomocí běžných nástrojů souborů, jako je Průzkumník Windows.

Poznámka

Před SQL Serverem 2014 (12.x) s názvem datových proudů souborů se místo toho použily k vytvoření interních souborů snímků. Pojmenované datové proudy souborů používaly formát <název_souboru.přípona>:MSSQL_DBCC<database_id_of_snapshot>. Pojmenované datové proudy souborů nejsou viditelné pomocí běžných nástrojů pro soubory, jako je Průzkumník Windows. Proto v SYSTÉMU SQL Server 2012 (11.x) a starších verzích může dojít k chybám 7926 a 5030 při spuštění příkazu DBCC CHECKDB pro databázové soubory umístěné na reFS-naformátovaný svazek. Je to proto, že streamy souborů nelze vytvořit v odolného systému souborů (RefS).

Kontrola a oprava dat FILESTREAM

Pokud je pro databázi a tabulku povolen fileSTREAM, můžete volitelně uložit varbinary(max) binární velké objekty (BLOBs) v systému souborů. Při použití DBCC CHECKDB v databázi, která ukládá bloby v systému souborů, dbCC kontroluje konzistenci na úrovni propojení mezi systémem souborů a databází.

Pokud například tabulka obsahuje varbinary(max) sloupec, který používá atribut FILESTREAM, DBCC CHECKDB zkontroluje, jestli mezi adresáři systému souborů a řádky tabulky, sloupci a hodnotami sloupců existuje mapování 1:1. DBCC CHECKDB může opravit poškození, pokud zadáte možnost REPAIR_ALLOW_DATA_LOSS. Chcete-li opravit poškození FILESTREAM, DBCC odstraní všechny řádky tabulky, které chybí data systému souborů.

Osvědčené postupy

Doporučujeme použít možnost PHYSICAL_ONLY pro časté použití v produkčních systémech. Použití PHYSICAL_ONLY může výrazně zkrátit dobu běhu pro DBCC CHECKDB u velkých databází. Doporučujeme také pravidelně spouštět DBCC CHECKDB bez možností. Četnost těchto spuštění závisí na jednotlivých firmách a jejich produkčních prostředích.

Ve službě Azure SQL Managed Instance musí dostupný prostor úložiště obsahovat celý interní soubor snímku databáze vytvořený DBCC CHECKDBbez ohledu na to, kolik dat skutečně používá. To může vést k situaci, kdy provádění DBCC CHECKDB ve velmi velké, ale řídké databázi (velikost dat je mnohem menší než velikost souboru databáze) selže kvůli nedostatku místa ve spravované instanci SQL. Pokud DBCC CHECKDB během provádění spotřebuje veškerý dostupný prostor úložiště, zobrazí se následující chybová zpráva:

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.

Paralelní kontrola objektů

Ve výchozím nastavení DBCC CHECKDB provádí paralelní kontrolu objektů. Stupeň paralelismu je automaticky určen procesorem dotazů. Maximální stupeň paralelismu se konfiguruje stejně jako paralelní dotazy. Chcete-li omezit maximální počet procesorů dostupných pro kontrolu DBCC, použijte sp_configure. Další informace naleznete v tématu Konfigurace serveru: maximální stupeň paralelismu. Paralelní kontrolu lze zakázat pomocí příznaku trasování 2528. Další informace najdete v tématu příznaky trasování.

Poznámka

Tato funkce není dostupná v každé edici SQL Serveru. Další informace najdete v části o možnostech správy RDBMS edicí a podporovaných funkcí sql Serveru 2022.

Vysvětlení chybových zpráv DBCC

Po dokončení příkazu DBCC CHECKDB se do protokolu chyb SQL Serveru zapíše zpráva. Pokud se příkaz DBCC úspěšně spustí, zpráva indikuje úspěch a dobu, po kterou se příkaz spustil. Pokud se příkaz DBCC zastaví před dokončením kontroly kvůli chybě, zpráva indikuje, že příkaz byl ukončen, stavová hodnota a doba spuštění příkazu. Následující tabulka uvádí a popisuje stavové hodnoty, které lze zahrnout do zprávy.

Stát	Popis
`0`	Byla vyvolána chyba 8930. To značí poškození metadat, která ukončila příkaz DBCC.
`1`	Byla vyvolána chyba 8967. Došlo k vnitřní chybě DBCC.
`2`	Při opravě databáze v nouzovém režimu došlo k chybě.
`3`	To značí poškození metadat, která ukončila příkaz DBCC.
`4`	Bylo zjištěno porušení kontrolního výrazu nebo přístupu.
`5`	Došlo k neznámé chybě, která ukončila příkaz DBCC.

SQL Server zaznamenává datum a čas spuštění kontroly konzistence pro databázi bez chyb (nebo kontroly čisté konzistence). To se označuje jako last known clean check. Při prvním spuštění databáze se toto datum zapíše do protokolu událostí (EventID-17573) a protokol chyb v následujícím formátu:

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.

Zasílání zpráv o chybách

V adresáři LOG SYSTÉMU SQL Server se vytvoří výpis zásobníku (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp), kdykoli DBCC CHECKDB zjistí chybu poškození. Pokud je pro instanci SQL Serveru povolená funkce používání funkcí shromažďování dat a funkce zasílání zpráv o chybách, soubor se automaticky přepošla do Microsoftu. Shromážděná data se používají ke zlepšení funkčnosti SQL Serveru. Soubor s výpisem paměti obsahuje výsledky příkazu DBCC CHECKDB a další diagnostický výstup. Přístup je omezen na účet služby SQL Server a členy role správce systému. Ve výchozím nastavení obsahuje role správce systému všechny členy skupiny Windows BUILTIN\Administrators a skupinu místního správce. Pokud proces shromažďování dat selže, příkaz DBCC se nezdaří.

Řešení chyb

Pokud DBCC CHECKDBohlásí nějaké chyby, doporučujeme obnovit databázi ze zálohy databáze místo spuštění DBCC CHECKDB s jednou z možností REPAIR_*. Pokud neexistuje žádná záloha, spuštění opraví nahlášené chyby. Možnost opravy, která se má použít, je určena na konci seznamu ohlášených chyb. Oprava chyb pomocí možnosti REPAIR_ALLOW_DATA_LOSS však může vyžadovat odstranění některých stránek, a proto některá data.

Za určitých okolností mohou být hodnoty zadány do databáze, které nejsou platné nebo mimo rozsah na základě datového typu sloupce. DBCC CHECKDB dokáže rozpoznat hodnoty sloupců, které nejsou platné pro všechny datové typy sloupců. Proto spuštění DBCC CHECKDB s možností DATA_PURITY u databází, které byly upgradovány z dřívějších verzí SQL Serveru, může odhalit existující chyby hodnoty sloupce. Protože SQL Server nemůže tyto chyby automaticky opravit, musí být hodnota sloupce aktualizována ručně. Pokud CHECKDB takovou chybu zjistí, CHECKDB vrátí upozornění, číslo chyby 2570 a informace k identifikaci ovlivněného řádku a ruční opravě chyby.

Opravu lze provést v rámci transakce uživatele, aby uživatel mohl vrátit zpět provedené změny. Pokud jsou opravy vráceny zpět, databáze stále obsahuje chyby a musí být obnovena ze zálohy. Po dokončení oprav zálohujte databázi.

Řešení chyb v režimu tísňového volání databáze

Pokud je databáze nastavena na nouzový režim pomocí příkazu ALTER DATABASE, DBCC CHECKDB může v databázi provést některé speciální opravy, pokud je zadána možnost REPAIR_ALLOW_DATA_LOSS. Tyto opravy můžou umožňovat obvykle neobnovitelné databáze v fyzicky konzistentním stavu. Tyto opravy by se měly používat jako poslední možnost a pouze v případě, že nemůžete obnovit databázi ze zálohy. Pokud je databáze nastavena na nouzový režim, je databáze označena READ_ONLY, protokolování je zakázáno a přístup je omezen na členy správce systému pevné role serveru.

Poznámka

Příkaz DBCC CHECKDB nelze spustit v nouzovém režimu v uživatelské transakci a vrátit transakci zpět po spuštění.

Pokud je databáze v nouzovém režimu a DBCC CHECKDB se spustí klauzule REPAIR_ALLOW_DATA_LOSS, provede se následující akce:

DBCC CHECKDB používá stránky, které byly označené jako nepřístupné kvůli chybám vstupně-výstupních operací nebo kontrolního součtu, jako by k chybám nedošlo. Tím se zvýší šance na obnovení dat z databáze.
DBCC CHECKDB se pokusí obnovit databázi pomocí běžných technik obnovení založených na protokolu.
Pokud obnovení databáze není úspěšné z důvodu poškození transakčního protokolu, transakční protokol se znovu sestaví. Opětovné sestavení transakčního protokolu může vést ke ztrátě transakční konzistence.

Varování

Možnost REPAIR_ALLOW_DATA_LOSS může způsobit větší ztrátu dat, než když obnovíte z poslední známé dobré zálohy. Viz upozornění na ztrátu dat s REPAIR_ALLOW_DATA_LOSS

Pokud je příkaz DBCC CHECKDB úspěšný, databáze je fyzicky konzistentní a stav databáze je nastavený na HODNOTU ONLINE. Databáze však může obsahovat jednu nebo více transakčních nekonzistencí. Doporučujeme spustit DBCC CHECKCONSTRAINTS identifikovat případné chyby obchodní logiky a okamžitě zálohovat databázi.

Pokud příkaz DBCC CHECKDB selže, databáze se nedá opravit.

Upozornění na ztrátu dat s REPAIR_ALLOW_DATA_LOSS

Možnost REPAIR_ALLOW_DATA_LOSS je podporovanou funkcí SQL Serveru. Nemusí ale být vždy nejlepší volbou pro přenesení databáze do fyzicky konzistentního stavu. V případě úspěchu může REPAIR_ALLOW_DATA_LOSS způsobit ztrátu dat.

Ve skutečnosti může dojít ke ztrátě více dat, než kdyby uživatel databázi obnovil z poslední známé dobré zálohy. Microsoft vždy doporučuje obnovení uživatele z poslední známé dobré zálohy jako primární metodu pro zotavení z chyb hlášených DBCC CHECKDB.

Možnost REPAIR_ALLOW_DATA_LOSS je není alternativou k obnovení ze známé dobré zálohy. Je to nouzové poslední možností se doporučuje použít pouze v případě, že obnovení ze zálohy není možné.

Po opětovném sestavení protokolu neexistuje žádná úplná záruka ACID.

Po opětovném sestavení protokolu se DBCC CHECKDB automaticky provede a sestavy a opraví problémy s fyzickou konzistencí.

Konzistence logických dat a vynucená omezení obchodní logiky se musí ověřit ručně.

Velikost transakčního protokolu je ponechána na výchozí velikosti a musí být ručně upravena zpět na její poslední velikost.

Spuštění DBCC CHECKDB s REPAIR_ALLOW_DATA_LOSS v replikovaných databázích

Spuštění příkazu DBCC CHECKDB s možností REPAIR_ALLOW_DATA_LOSS může ovlivnit uživatelské databáze (databáze publikování a předplatná) a distribuční databázi používanou replikací. Databáze publikování a odběru zahrnují publikované tabulky a tabulky metadat replikace. Mějte na paměti následující potenciální problémy v těchto databázích:

Publikované tabulky. Akce prováděné procesem CHECKDB pro opravu poškozených uživatelských dat se nemusí replikovat:
Při slučování replikace se ke sledování změn publikovaných tabulek používají triggery. Pokud jsou řádky vloženy, aktualizovány nebo odstraněny procesem CHECKDB, triggery se neaktivují; proto se změna nereplikuje.
Transakční replikace používá transakční protokol ke sledování změn publikovaných tabulek. Agent Log Reader pak tyto změny přesune do distribuční databáze. Některé opravy DBCC, i když protokolované, není možné replikovat agentem čtenáře protokolů. Pokud je například datová stránka uvolněna procesem CHECKDB, agent Log Reader nepřeloží tuto polohu na příkaz DELETE; proto se změna nereplikuje.
Tabulky metadat replikace Akce prováděné procesem CHECKDB pro opravu poškozených tabulek metadat replikace vyžadují odebrání a změně konfigurace replikace.

Pokud musíte spustit příkaz DBCC CHECKDB s možností REPAIR_ALLOW_DATA_LOSS v uživatelské databázi nebo distribuční databázi:

Vyřaďte systém do stavu nečinnosti: Zastavte aktivitu v databázi a ve všech ostatních databázích v topologii replikace a pak se pokuste synchronizovat všechny uzly. Další informace najdete v tématu nečinnosti topologie replikace (Transact-SQL programování replikace).
Spusťte DBCC CHECKDB.
Pokud sestava DBCC CHECKDB obsahuje opravy všech tabulek v distribuční databázi nebo jakékoli tabulky metadat replikace v uživatelské databázi, odeberte a znovu nakonfigurujte replikaci. Další informace naleznete v tématu Zakázání publikování a distribuce.
Pokud sestava DBCC CHECKDB obsahuje opravy pro všechny replikované tabulky, proveďte ověření dat, abyste zjistili, jestli existují rozdíly mezi daty v publikaci a databázích odběrů.

Sada výsledků

DBCC CHECKDB vrátí následující sadu výsledků. Hodnoty se mohou lišit s výjimkou případů, kdy jsou zadány možnosti ESTIMATEONLY, PHYSICAL_ONLYnebo NO_INFOMSGS:

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 při zadání NO_INFOMSGS vrátí následující sadu výsledků (zprávu):

The command(s) completed successfully.

DBCC CHECKDB vrátí následující sadu výsledků při zadání PHYSICAL_ONLY:

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 vrátí následující sadu výsledků při zadání ESTIMATEONLY.

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.

Dovolení

Vyžaduje členství v pevné roli serveru nebo db_owner pevné databázové roli.

Příklady

A. Kontrola aktuální i jiné databáze

Následující příklad spustí DBCC CHECKDB pro aktuální databázi a pro databázi AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO

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

B. Kontrola aktuální databáze a potlačení informačních zpráv

Následující příklad zkontroluje aktuální databázi a potlačí všechny informační zprávy.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

DBCC (Transact-SQL)
zobrazit velikost zhuštěného souboru snímku databáze (Transact-SQL)
sp_helpdb (Transact-SQL)
systémových tabulek (Transact-SQL)

Sdílet prostřednictvím

DBCC CHECKDB (Transact-SQL)

Syntax

Argumenty

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Poznámky

Provádění kontrol logické konzistence u indexů

Informace o úrovni kompatibility databáze

Snímek interní databáze

Jak DBCC CHECKDB vytvoří interní databázi snímků od SQL Serveru 2014

Kontrola a oprava dat FILESTREAM

Osvědčené postupy

Paralelní kontrola objektů

Vysvětlení chybových zpráv DBCC

Zasílání zpráv o chybách

Řešení chyb

Řešení chyb v režimu tísňového volání databáze

Upozornění na ztrátu dat s REPAIR_ALLOW_DATA_LOSS

Spuštění DBCC CHECKDB s REPAIR_ALLOW_DATA_LOSS v replikovaných databázích

Sada výsledků

Dovolení

Příklady

A. Kontrola aktuální i jiné databáze

B. Kontrola aktuální databáze a potlačení informačních zpráv

Váš názor

Další materiály

Sdílet prostřednictvím

DBCC CHECKDB (Transact-SQL)

Syntax

Argumenty

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Poznámky

Provádění kontrol logické konzistence u indexů

Informace o úrovni kompatibility databáze

Snímek interní databáze

Jak DBCC CHECKDB vytvoří interní databázi snímků od SQL Serveru 2014

Kontrola a oprava dat FILESTREAM

Osvědčené postupy

Paralelní kontrola objektů

Vysvětlení chybových zpráv DBCC

Zasílání zpráv o chybách

Řešení chyb

Řešení chyb v režimu tísňového volání databáze

Upozornění na ztrátu dat s REPAIR_ALLOW_DATA_LOSS

Spuštění DBCC CHECKDB s REPAIR_ALLOW_DATA_LOSS v replikovaných databázích

Sada výsledků

Dovolení

Příklady

A. Kontrola aktuální i jiné databáze

B. Kontrola aktuální databáze a potlačení informačních zpráv

Související obsah

Váš názor

Další materiály