DBCC CHECKDB (Transact-SQL)

• 14.12.2017
• 22 minut čtení
• • p
  • M
  • m
  • M
  • P
  • +3

Týká se: SQL Server (všechny podporované verze) Azure SQL Database

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

• Provede DBCC CHECKALLOC na databázi.
• Provede DBCC CHECKTABLE na každé tabulce a zobrazení v databázi.
• Provede DBCC CHECKCATALOG na databázi.
• Ověří obsah každého indexovaného zobrazení v databázi.
• Ověřuje konzistenci na úrovni odkazů mezi metadaty tabulky a adresáři a soubory souborového systému při ukládání varbinárních(max) dat v souborovém systému pomocí FILESTREAM.
• Ověřuje data Service Broker v databázi.

To znamená, že příkazy DBCC CHECKALLOC, DBCC CHECKTABLE nebo DBCC CHECKCATALOG není nutné spouštět odděleně od příkazu DBCC CHECKDB. Podrobnější informace o kontrolách, které tyto příkazy provádějí, najdete v popisech těchto příkazů.

Syntaktické konvence jazyka Transact-SQL

Syntaxe

DBCC CHECKDB ) ] } ] ] 

Argumenty

jméno_databáze | ID_databáze | 0
Je název nebo ID databáze, pro kterou se mají provádět kontroly integrity. Není-li zadáno nebo je-li zadáno 0, použije se aktuální databáze. Názvy databází musí být v souladu s pravidly pro identifikátory.

NOINDEX
Určuje, že se nemají provádět intenzivní kontroly neshlukových indexů pro uživatelské tabulky. Tím se snižuje celková doba 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. Volby REPAIR používejte pouze v krajním případě. Aby bylo možné použít jednu z následujících možností opravy, musí být zadaná databáze v režimu jednoho uživatele.

REPAIR_ALLOW_DATA_LOSS
Pokusí se opravit všechny nahlášené chyby. Tyto opravy mohou způsobit určitou ztrátu dat.

REPAIR_FAST
Zachovává syntaxi pouze pro zpětnou kompatibilitu. Neprovádí žádné opravné akce.

REPAIR_REBUILD
Provádí opravy, které nemají možnost ztráty dat. Může se jednat o rychlé opravy, jako je oprava chybějících řádků v neshlukovaných indexech, a časově náročnější opravy, jako je přestavba indexu.
Tento argument neopravuje chyby zahrnující data FILESTREAM.

ALL_ERRORMSGS
Zobrazí všechny nahlášené chyby na objekt. Ve výchozím nastavení se zobrazí všechna chybová hlášení. Zadání nebo vynechání této volby nemá žádný vliv. Chybová hlášení jsou seřazena podle ID objektu, s výjimkou hlášení generovaných z databáze tempdb.

EXTENDED_LOGICAL_CHECKS
Pokud je úroveň kompatibility 100 ( SQL Server 2008) nebo vyšší, provádí kontroly logické konzistence indexovaného zobrazení, indexů XML a prostorových indexů, pokud jsou přítomny.
Další informace naleznete v části Provádění kontrol logické konzistence indexů v části Poznámky dále v tomto tématu.

NO_INFOMSGS
Potlačí všechna informační hlášení.

TABLOCK
Přinutí DBCC CHECKDB získat zámky místo použití interního snímku databáze. To zahrnuje krátkodobý exkluzivní (X) zámek databáze. TABLOCK způsobí rychlejší běh DBCC CHECKDB v databázi při velkém zatížení, ale snižuje souběžnost dostupnou v databázi během běhu DBCC CHECKDB.

ESTIMATEONLY
Zobrazí odhadované množství místa v tempdb, které je nutné pro spuštění DBCC CHECKDB se všemi ostatními zadanými volbami. Vlastní kontrola databáze se neprovádí.

PHYSICAL_ONLY
Omezuje kontrolu na integritu fyzické struktury záhlaví stránek a záznamů a konzistenci alokace databáze. Tato kontrola je navržena tak, aby poskytovala malou režii kontroly fyzické konzistence databáze, ale může také odhalit roztržené stránky, selhání kontrolního součtu a běžné hardwarové poruchy, které mohou ohrozit uživatelská data.
Plné spuštění DBCC CHECKDB může trvat podstatně déle než u dřívějších verzí. K tomuto chování dochází, protože:

• Logické kontroly jsou komplexnější.
• Některé základní struktury, které je třeba zkontrolovat, jsou složitější.
• Bylo zavedeno mnoho nových kontrol, které zahrnují nové funkce.
  Použití volby PHYSICAL_ONLY proto může způsobit mnohem kratší dobu běhu DBCC CHECKDB u velkých databází a doporučuje se pro časté použití v produkčních systémech. I nadále doporučujeme pravidelně provádět úplné spuštění DBCC CHECKDB. Četnost těchto běhů závisí na faktorech specifických pro jednotlivé podniky a produkční prostředí.
  Tento argument vždy implikuje NO_INFOMSGS a není povolen s žádnou z možností opravy.

DATA_PURITY
Způsobí, že DBCC CHECKDB zkontroluje databázi na hodnoty sloupců, které nejsou platné nebo jsou mimo rozsah. DBCC CHECKDB například zjistí sloupce s hodnotami data a času, které jsou větší nebo menší než přípustný rozsah pro datový typ datetime; nebo sloupce s desetinným nebo přibližným číselným datovým typem s hodnotami stupnice nebo přesnosti, které nejsou platné.
Kontroly integrity hodnot sloupců jsou ve výchozím nastavení povoleny a nevyžadují volbu DATA_PURITY. U databází upgradovaných z dřívějších verzí SQL Serveru nejsou kontroly hodnot sloupců ve výchozím nastavení povoleny, dokud není v databázi bezchybně spuštěn příkaz DBCC CHECKDB WITH DATA_PURITY. Poté bude DBCC CHECKDB kontrolovat integritu hodnot sloupců ve výchozím nastavení. Další informace o tom, jak může být CHECKDB ovlivněna upgradem databáze z dřívějších verzí SQL Serveru, najdete v části Poznámky dále v tomto tématu.

Chyby validace hlášené touto volbou nelze opravit pomocí možností opravy DBCC. Informace o ruční opravě těchto chyb naleznete v článku znalostní báze 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.

MAXDOP
Týká se: SQL Server ( SQL Server 2014 (12.x) SP2 a novější).

Přepisuje konfigurační volbu max. stupně paralelizmu sp_configure pro příkaz. MAXDOP může překročit hodnotu nakonfigurovanou pomocí sp_configure. Pokud MAXDOP překročí hodnotu nakonfigurovanou pomocí nástroje Resource Governor, použije databázový engine SQL Serveru hodnotu MAXDOP nástroje Resource Governor, popsanou v části ALTER WORKLOAD GROUP. Při použití nápovědy k dotazu MAXDOP platí všechna sémantická pravidla použitá s možností konfigurace max. stupně paralelizmu. Další informace naleznete v části Konfigurace možnosti konfigurace serveru max. stupeň paralelizmu.

Poznámky

DBCC CHECKDB nezkoumá zakázané indexy. Další informace o zakázaných indexech najdete v části Zakázané indexy a omezení.

Je-li uživatelsky definovaný typ označen jako byte ordered, musí existovat pouze jedna serializace uživatelsky definovaného typu. Neexistence konzistentní serializace uživatelsky definovaných typů s pořadím bajtů způsobuje chybu 2537 při spuštění DBCC CHECKDB. Další informace naleznete v části Požadavky na uživatelsky definované typy.

Protože je databáze Resource modifikovatelná pouze v režimu jednoho uživatele, nelze na ní přímo spustit příkaz DBCC CHECKDB. Když je však příkaz DBCC CHECKDB spuštěn proti hlavní databázi, spustí se druhý příkaz CHECKDB také interně na databázi Resource. To znamená, že příkaz DBCC CHECKDB může vrátit další výsledky. Příkaz vrací další sady výsledků, pokud nejsou nastaveny žádné volby nebo pokud je nastavena volba PHYSICAL_ONLY nebo ESTIMATEONLY.

Počínaje verzí SQL Server 2005 (9.x) SP2 již provádění příkazu DBCC CHECKDB nečistí mezipaměť plánů instance SQL Serveru. Před SQL Server 2005 (9.x) SP2 provedení DBCC CHECKDB vymaže mezipaměť plánu. Vymazání mezipaměti plánu způsobí rekompilaci všech pozdějších prováděcích plánů a může způsobit náhlé, dočasné snížení výkonu dotazu.

Provádění kontrol logické konzistence na indexech

Kontrola logické konzistence na indexech se liší podle úrovně kompatibility databáze takto:

• Pokud je úroveň kompatibility 100 (SQL Server 2008) nebo vyšší:
• Pokud není zadáno NOINDEX, provede DBCC CHECKDB kontrolu fyzické i logické konzistence jedné tabulky a všech jejích indexů, které nejsou shlukové. U indexů XML, prostorových indexů a indexovaných pohledů se však ve výchozím nastavení provádějí pouze kontroly fyzické konzistence.
• Je-li zadáno WITH EXTENDED_LOGICAL_CHECKS, provádějí se logické kontroly u indexovaného pohledu, indexů XML a prostorových indexů, pokud jsou přítomny. Ve výchozím nastavení jsou kontroly fyzické konzistence prováděny před kontrolami logické konzistence. Pokud je zadáno také NOINDEX, provedou se pouze logické kontroly.

Tyto logické kontroly konzistence křížově kontrolují interní indexovou tabulku indexového objektu s uživatelskou tabulkou, na kterou se odkazuje. Pro nalezení odlehlých řádků je zkonstruován interní dotaz, který provede úplný průnik interní a uživatelské tabulky. Spuštění tohoto dotazu může mít velmi vysoký 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 indexy, které nesouvisí s fyzickým poškozením, nebo pokud byly vypnuty kontrolní součty na úrovni stránek a máte podezření na hardwarové poškození na úrovni sloupců.

• Je-li index filtrovaným indexem, provede DBCC CHECKDB kontrolu konzistence, aby ověřil, zda položky indexu splňují predikát filtru.
• Je-li úroveň kompatibility 90 nebo nižší, pokud není zadána hodnota NOINDEX, provede DBCC CHECKDB kontrolu fyzické i logické konzistence jedné tabulky nebo indexovaného zobrazení a všech jejich indexů, které nejsou shlukové, a indexů XML. Prostorové indexy nejsou podporovány.
• Počínaje SQL Serverem 2016 se ve výchozím nastavení neprovádějí dodatečné kontroly persistujících vypočtených sloupců, sloupců UDT a filtrovaných indexů, aby se zabránilo nákladnému vyhodnocování výrazů. Tato změna výrazně zkracuje dobu trvání CHECKDB proti 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 volba EXTENDED_LOGICAL_CHECKS, budou vyhodnocení výrazů prováděna navíc k již přítomným logickým kontrolám (indexované zobrazení, indexy XML a prostorové indexy) jako součást volby EXTENDED_LOGICAL_CHECKS.

Zjištění úrovně kompatibility databáze

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

Interní snímek databáze

DBCC CHECKDB používá interní snímek databáze pro transakční konzistenci potřebnou k provedení těchto kontrol. Tím se zabrání problémům s blokováním a souběhem při provádění těchto příkazů. Další informace naleznete v části Zobrazení velikosti řídkého souboru snímku databáze (Transact-SQL) a v části Použití interního snímku databáze v programu DBCC (Transact-SQL). Pokud snímek nelze vytvořit nebo je zadán TABLOCK, DBCC CHECKDB získá zámky, aby dosáhl požadované konzistence. V tomto případě je pro provedení kontroly alokace vyžadován exkluzivní zámek databáze a pro provedení kontroly tabulek jsou vyžadovány sdílené zámky tabulek.DBCC CHECKDB selže při spuštění proti masteru, pokud nelze vytvořit interní snímek databáze.Při spuštění DBCC CHECKDB proti tempdb se neprovádí žádná kontrola alokace ani kontrola katalogu a pro provedení kontroly tabulek je nutné získat sdílené zámky tabulek. Je to proto, že z výkonnostních důvodů nejsou na tempdb k dispozici snímky databáze. To znamená, že nelze dosáhnout požadované transakční konzistence.V systému Microsoft SQL Server 2012 nebo starší verzi systému SQL Server se při spuštění příkazu DBCC CHECKDB pro databázi, jejíž soubory jsou umístěny na svazku s formátem ReFS, můžete setkat s chybovými zprávami. Další informace naleznete v článku znalostní báze 2974455: DBCC CHECKDB behavior when the SQL Server database is located on an ReFS volume.

Kontrola a oprava dat FILESTREAM

Pokud je pro databázi a tabulku povolen FILESTREAM, můžete v systému souborů volitelně ukládat varbinary(max) binary large objects (BLOB). Při použití DBCC CHECKDB u databáze, která ukládá BLOBy v souborovém systému, kontroluje DBCC konzistenci na úrovni odkazů mezi souborovým systémem a databází. například pokud tabulka obsahuje sloupec varbinary(max), který používá atribut FILESTREAM, DBCC CHECKDB zkontroluje, zda existuje mapování jedna ku jedné mezi adresáři a soubory souborového systému a řádky, sloupci a hodnotami sloupců tabulky. DBCC CHECKDB může opravit poškození, pokud zadáte volbu REPAIR_ALLOW_DATA_LOSS. Pro opravu poškození FILESTREAM odstraní DBCC všechny řádky tabulky, ve kterých chybí data souborového systému.

Nejlepší postupy

Při častém používání v produkčních systémech doporučujeme používat volbu PHYSICAL_ONLY. Použití volby PHYSICAL_ONLY může výrazně zkrátit dobu běhu programu DBCC CHECKDB u velkých databází. Doporučujeme také pravidelně spouštět DBCC CHECKDB bez volby. Jak často byste měli tato spuštění provádět, závisí na jednotlivých podnicích a jejich produkčních prostředích.

Paralelní kontrola objektů

Ve výchozím nastavení provádí DBCC CHECKDB paralelní kontrolu objektů. Stupeň paralelismu je automaticky určen procesorem dotazu. 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 příkaz sp_configure. Další informace naleznete v části Konfigurace maximálního stupně paralelismu – možnost konfigurace serveru. Paralelní kontrolu lze zakázat pomocí příznaku trasování 2528. Další informace naleznete v části Příznaky trasování (Transact-SQL).

Pochopení 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ě provede, je ve zprávě uveden úspěch a doba, po kterou příkaz běžel. Pokud se příkaz DBCC zastaví před dokončením kontroly z důvodu chyby, zpráva uvádí, že příkaz byl ukončen, hodnotu stavu a dobu, po kterou příkaz běžel. Následující tabulka uvádí a popisuje hodnoty stavu, které mohou být obsaženy ve zprávě.

State	Description
0	Bylo vyvoláno číslo chyby 8930. To znamená poškození metadat, které ukončilo příkaz DBCC.
1	Byla vyvolána chyba číslo 8967. Došlo k interní chybě DBCC.
2	Při opravě databáze v nouzovém režimu došlo k chybě.
3	Oznamuje poškození v metadatech, které ukončilo příkaz DBCC.
4	Bylo zjištěno porušení assertu nebo přístupu.
5	Vyskytla se neznámá chyba, která ukončila příkaz DBCC.

Hlášení chyb

Vždy, když DBCC CHECKDB zjistí chybu poškození, vytvoří se v adresáři SQL Server LOG výpisový soubor (SQLDUMP*nnnn*.txt). Pokud jsou pro instanci SQL Serveru povoleny funkce Feature Usage data collection a Error Reporting, je soubor automaticky předán společnosti Microsoft. Shromážděná data se používají ke zlepšení funkčnosti serveru SQL Server. výpisový soubor obsahuje výsledky příkazu DBCC CHECKDB a další diagnostické výstupy. Přístup je omezen na účet služby SQL Server a členy role sysadmin. Ve výchozím nastavení obsahuje role sysadmin všechny členy skupiny Windows BUILTIN\Administrators a skupiny místního správce. Příkaz DBCC neselže, pokud proces sběru dat selže.

Řešení chyb

Pokud příkaz DBCC CHECKDB hlásí nějaké chyby, doporučujeme obnovit databázi ze zálohy databáze místo spuštění příkazu REPAIR s jednou z možností REPAIR. Pokud žádná záloha neexistuje, spuštění opravy opraví nahlášené chyby. Možnost opravy, která se má použít, je uvedena na konci seznamu hláš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 tedy i některých dat.

Za určitých okolností mohou být do databáze zadány hodnoty, které nejsou platné nebo jsou mimo rozsah podle datového typu sloupce. DBCC CHECKDB může odhalit hodnoty sloupců, které nejsou platné pro všechny datové typy sloupců. Proto může spuštění DBCC CHECKDB s možností DATA_PURITY v databázích, které byly aktualizovány z dřívějších verzí SQL Serveru, odhalit již existující chyby hodnot sloupců. Protože SQL Server nemůže tyto chyby automaticky opravit, je třeba hodnotu sloupce aktualizovat ručně. Pokud CHECKDB takovou chybu zjistí, vrátí varování, číslo chyby 2570 a informace pro identifikaci postiženého řádku a ruční opravu chyby.

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

Řešení chyb v nouzovém režimu databáze

Pokud byla databáze nastavena do nouzového režimu pomocí příkazu ALTER DATABASE, může program DBCC CHECKDB provést některé speciální opravy databáze, pokud je zadána volba REPAIR_ALLOW_DATA_LOSS. Tyto opravy mohou umožnit obnovení běžně neobnovitelných databází ve fyzicky konzistentním stavu. Tyto opravy by měly být použity jako poslední možnost a pouze v případě, že nelze obnovit databázi ze zálohy. Když je databáze nastavena do nouzového režimu, je databáze označena jako READ_ONLY, je zakázáno protokolování a přístup je omezen na členy pevné role serveru sysadmin.

Pokud je databáze v nouzovém režimu a je spuštěn příkaz DBCC CHECKDB s klauzulí REPAIR_ALLOW_DATA_LOSS, provedou se následující akce:

• DBCC CHECKDB používá stránky, které byly označeny jako nedostupné z důvodu chyb I/O nebo kontrolního součtu, jako by k chybám nedošlo. Tím se zvýší šance na obnovu dat z databáze.
• DBCC CHECKDB se pokusí obnovit databázi pomocí běžných technik obnovy založených na protokolu.
• Pokud je z důvodu poškození protokolu transakcí obnova databáze neúspěšná, protokol transakcí se obnoví. Přestavba protokolu transakcí může vést ke ztrátě konzistence transakcí.

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

Provedení příkazu DBCC CHECKDB s volbou REPAIR_ALLOW_DATA_LOSS v replikovaných databázích

Provedení příkazu DBCC CHECKDB s volbou REPAIR_ALLOW_DATA_LOSS může ovlivnit uživatelské databáze (databáze publikací a předplatného) a distribuční databázi používanou replikací. Publikační databáze a databáze předplatného zahrnují publikované tabulky a tabulky metadat replikace. Dávejte pozor na následující možné problémy v těchto databázích:

• Publikované tabulky. Akce prováděné procesem CHECKDB za účelem opravy poškozených uživatelských dat nemusí být replikovány:
• Merge replikace používá ke sledování změn v publikovaných tabulkách triggery. Pokud jsou řádky vloženy, aktualizovány nebo odstraněny procesem CHECKDB, spouštěče se nespustí, a proto se změna nereplikuje.
• Transakční replikace používá ke sledování změn v publikovaných tabulkách protokol transakcí. Agent pro čtení protokolů pak tyto změny přesune do distribuční databáze. Některé opravy DBCC, přestože jsou zaznamenány v protokolu, nemůže agent pro čtení protokolů replikovat. Pokud je například datová stránka dealokována procesem CHECKDB, agent Log Reader to nepřevede na příkaz DELETE; změna proto není replikována.
• Replikace metadatových tabulek. Akce prováděné procesem CHECKDB za účelem opravy poškozených tabulek metadat replikace vyžadují odstranění a rekonfiguraci replikace.

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

1. Ukončete systém: Ukončete činnost v databázi a ve všech ostatních databázích v topologii replikace a poté se pokuste synchronizovat všechny uzly. Další informace naleznete v části Quiesce a Replication Topology (Replication Transact-SQL Programming).
2. Provedení DBCC CHECKDB.
3. Pokud zpráva DBCC CHECKDB obsahuje opravy pro některé tabulky v distribuční databázi nebo pro některé tabulky metadat replikace v uživatelské databázi, odstraňte a znovu nakonfigurujte replikaci. Další informace naleznete v části Zakázat publikování a distribuci.
4. Pokud hlášení DBCC CHECKDB obsahuje opravy pro některé replikované tabulky, proveďte ověření dat, abyste zjistili, zda existují rozdíly mezi daty v publikační a předplatitelské databázi.

Sady výsledků

DBCC CHECKDB vrací následující sadu výsledků. Hodnoty se mohou lišit s výjimkou případů, kdy jsou zadány možnosti ESTIMATEONLY, PHYSICAL_ONLY nebo 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 vrací následující sadu výsledků (zprávu), pokud je zadána možnost NO_INFOMSGS:

 The command(s) completed successfully.

DBCC CHECKDB vrací následující sadu výsledků, když je zadáno 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 vrací následující sadu výsledků, když je zadáno 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.

Oprávnění

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

Příklady

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

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

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

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

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

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Viz také

DBCC (Transact-SQL)
Zobrazení velikosti řídkého souboru snímku databáze (Transact-SQL)
sp_helpdb (Transact-SQL)
Systémové tabulky (Transact-SQL)

.