Sdílet prostřednictvím

DBCC CHECKTABLE (Transact-SQL)

  • Článek

platí pro:SQL ServerAzure SQL Databaseazure SQL Managed Instance

Kontroluje integritu všech stránek a struktur, které tvoří tabulku nebo indexované zobrazení.

Transact-SQL konvence syntaxe

Syntax

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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

table_name | view_name

Tabulka nebo indexované zobrazení, pro které se mají spouštět kontroly integrity. Názvy tabulek nebo zobrazení musí splňovat pravidla pro identifikátory .

NOINDEX

Určuje, že by se neměly provádět náročné kontroly neclusterovaných indexů pro tabulky uživatelů. Tím se sníží celková doba provádění. NOINDEX nemá vliv na systémové tabulky, protože kontroly integrity se vždy provádějí na všech indexech systémových tabulek.

index_id

Identifikační číslo indexu (ID), pro které se mají spouštět kontroly integrity. Pokud index_id zadáte, DBCC CHECKTABLE spustí kontroly integrity pouze u daného indexu společně s haldou nebo clusterovaným indexem.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Určuje, že DBCC CHECKTABLE opravit nalezené chyby. Pokud chcete použít možnost opravy, musí být databáze v režimu jednoho uživatele.

  • REPAIR_ALLOW_DATA_LOSS

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

  • REPAIR_FAST

    Syntaxe se udržuje pouze kvůli zpětné kompatibilitě. Neprovádí se žádné akce opravy.

  • REPAIR_REBUILD

    Provádí opravy, které nemají možnost ztráty dat. Může to 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ý

Možnosti OPRAVIT použijte pouze jako poslední možnost. Pokud chcete opravit chyby, doporučujeme provést obnovení ze zálohy. Operace opravy nebere v úvahu žádná omezení, která mohou 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 opravu, spusťte DBCC CHECKTABLE 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 CHECKTABLE pomocí této možnosti zálohovat databázi.

ALL_ERRORMSGS

Zobrazí neomezený počet chyb. Ve výchozím nastavení se zobrazí všechny chybové zprávy. Zadání nebo vynechání této možnosti nemá žádný vliv.

EXTENDED_LOGICAL_CHECKS

Pokud je úroveň kompatibility 100, zavedená v SYSTÉMU SQL Server 2008 (10.0.x), provádí logické kontroly konzistence 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ů v části Poznámky dále v tomto článku.

NO_INFOMSGS

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

TABLOCK

Způsobí, že DBCC CHECKTABLE získat zámek sdílené tabulky místo použití interního snímku databáze. TABLOCK způsobí rychlejší spuštění DBCC CHECKTABLE u tabulky s velkým zatížením, ale sníží souběžnost dostupnou v tabulce během DBCC CHECKTABLE.

ESTIMATEONLY

Zobrazí odhadovanou velikost tempdb prostoru potřebného ke spuštění DBCC CHECKTABLE se všemi ostatními zadanými možnostmi.

PHYSICAL_ONLY

Omezuje kontrolu na integritu fyzické struktury stránky, záhlaví záznamů a fyzické struktury B-stromů. Tato kontrola je navržená tak, aby poskytovala malou režijní kontrolu fyzické konzistence tabulky, může tato kontrola také detekovat roztržené stránky a běžné chyby hardwaru, které můžou ohrozit data. Úplné spuštění DBCC CHECKTABLE může trvat výrazně déle než v předchozích verzích. K tomuto chování dochází z následujících důvodů:

  • 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.

Poznámka

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

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

Poznámka

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

DATA_PURITY

Způsobí, že DBCC CHECKTABLE zkontroluje, jestli tabulka neobsahuje hodnoty sloupců, které nejsou platné nebo mimo rozsah. Například DBCC CHECKTABLE 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 můžete pomocí DBCC CHECKTABLE WITH DATA_PURITY vyhledat a opravit chyby v konkrétní tabulce; Kontroly hodnot sloupců v tabulce ale nejsou ve výchozím nastavení povolené, dokud DBCC CHECKDB WITH DATA_PURITY v databázi nespustí chybu. Potom ve výchozím nastavení DBCC CHECKDB a DBCC CHECKTABLE kontrolovat integritu hodnot sloupců.

Chyby ověření hlášené touto možností nelze opravit pomocí možností opravy DBCC. Informace o ruční opravě těchto chyb naleznete v článku znalostní báze Knowledge Base 923247: Řešení chyby DBCC 2570 v SYSTÉMU SQL Server 2005 a novějších verzích.

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

MAXDOP

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

Přepíše maximální stupeň paralelismu možnost konfigurace sp_configure příkazu. MaxDOP může překročit hodnotu nakonfigurovanou pro sp_configure. Pokud hodnota MAXDOP překročí hodnotu nakonfigurovanou pro správce prostředků, použije databázový stroj hodnotu MAXDOP správce prostředků popsanou ve skupině ALTER WORKLOAD GROUP (Transact-SQL). Všechna sémantická pravidla používaná s maximálním stupněm konfigurace paralelismu se použijí při použití nápovědy k dotazu MAXDOP. Další informace najdete v tématu Konfigurace maximálního stupně paralelismu Možnosti konfigurace serveru.

Poznámka

Pokud je hodnota MAXDOP nastavená na nulu, server zvolí maximální stupeň paralelismu.

Poznámky

Poznámka

Pokud chcete provádět DBCC CHECKTABLE pro každou tabulku v databázi, použijte DBCC CHECKDB .

Pro zadanou tabulku DBCC CHECKTABLE zkontroluje následující:

  • Datové stránky indexu, obchodního objektu a přetečení řádků jsou správně propojené.
  • Indexy jsou ve správném pořadí řazení.
  • Ukazatele jsou konzistentní.
  • Data na každé stránce jsou rozumná, včetně počítaných sloupců.
  • Posuny stránek jsou rozumné.
  • Každý řádek v základní tabulce má v každém neclusterovaném indexu odpovídající řádek a naopak.
  • Každý řádek v dělené tabulce nebo indexu je ve správném oddílu.
  • Konzistence na úrovni propojení mezi systémem souborů a tabulkou při ukládání varbinary(max) dat v systému souborů pomocí FILESTREAM.

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 100 (SQL Server 2008 (10.0.x)) nebo vyšší:

    • Pokud není zadán NOINDEX, DBCC CHECKTABLE 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í indexové tabulky 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 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 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 CHECKTABLE provádí kontroly konzistence, aby ověřily, že položky indexu splňují predikát filtru.

  • Počínaje SQL Serverem 2016 (13.x), další kontroly trvalých počítaných sloupců, sloupců UDT a filtrovaných indexů se ve výchozím nastavení nespustí, aby se zabránilo drahým vyhodnocením výrazů. Tato změna výrazně zkracuje dobu trvání CHECKTABLE vůči databázím obsahujícím tyto objekty. Kontroly fyzické konzistence těchto objektů jsou však vždy dokončeny. Pouze v případě, že je zadána možnost EXTENDED_LOGICAL_CHECKS je provedena vyhodnocení výrazů, kromě již přítomných logických kontrol (indexované zobrazení, indexy XML a prostorové indexy) jako součást EXTENDED_LOGICAL_CHECKS možnosti.

  • Pokud je úroveň kompatibility 90 (SQL Server 2005 (9.x)) nebo menší, pokud není zadána NOINDEX, DBCC CHECKTABLE provádí kontroly fyzické i logické konzistence v jedné tabulce nebo indexovaném zobrazení a na všech jeho neclusterovaných a XML indexech. Prostorové indexy se nepodporují.

Informace o úrovni kompatibility databáze

Snímek interní databáze

DBCC CHECKTABLE používá interní snímek databáze k zajištění transakční konzistence, kterou musí tyto kontroly provést. Další informace najdete v tématu Zobrazení velikosti zhuštěného souboru snímku databáze (Transact-SQL) a použití interního snímku databáze DBTransact-SQLCC oddílu .

Pokud snímek nejde vytvořit nebo TABLOCK je zadaný, DBCC CHECKTABLE získá zámek sdílené tabulky, aby získal požadovanou konzistenci.

Poznámka

Pokud se DBCC CHECKTABLE spustí proti tempdb, musí získat zámek sdílené tabulky. 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.

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 CHECKTABLE v tabulce, která uchovává 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 CHECKTABLE zkontroluje, jestli mezi adresáři systému souborů a řádky tabulky, sloupci a hodnotami sloupců existuje mapování 1:1. DBCC CHECKTABLE 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, ve které chybí data systému souborů, a odstraní všechny adresáře a soubory, které nejsou namapované na řádek tabulky, sloupec nebo hodnotu sloupce.

Paralelní kontrola objektů

Ve výchozím nastavení DBCC CHECKTABLE provádí paralelní kontrolu objektů. Stupeň paralelismu je automaticky určen procesorem dotazů. Maximální stupeň paralelismu se konfiguruje stejným způsobem jako u paralelních dotazů. Chcete-li omezit maximální počet procesorů dostupných pro kontrolu DBCC, použijte sp_configure. Další informace najdete v tématu Konfigurace maximálního stupně paralelismu Možnosti konfigurace serveru.

Paralelní kontrolu lze zakázat pomocí příznaku trasování 2528. Další informace naleznete v tématu příznaky trasování (Transact-SQL).

Poznámka

Během DBCC CHECKTABLE operace musí být bajty uložené ve sloupci typu definovaném uživatelem seřazené podle bajtů stejné jako vypočítaná serializace hodnoty uživatelem definovaného typu. Pokud to není pravda, rutina DBCC CHECKTABLE hlásí chybu konzistence.

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 CHECKTABLE se do protokolu chyb SQL Serveru zapíše zpráva. Pokud se příkaz DBCC úspěšně spustí, zpráva značí úspěšné dokončení 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, hodnota stavu 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. Označuje poškození metadat, která způsobila ukončení příkazu 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 Označuje poškození metadat, která způsobila ukončení příkazu 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.

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

V adresáři SQL Serveru LOG se vytvoří soubor s mini výpisem paměti (SQLDUMP<nnnn>.txt), kdykoli DBCC CHECKTABLE 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 CHECKTABLE a další diagnostický výstup. Soubor omezil volitelné seznamy řízení přístupu (DACL). 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 skupiny místního správce. Pokud proces shromažďování dat selže, příkaz DBCC se nezdaří.

Řešení chyb

Pokud DBCC CHECKTABLE hlásí nějaké chyby, doporučujeme obnovit databázi ze zálohy databáze místo spuštění funkce OPRAVIT pomocí jedné z možností OPRAVIT. Pokud neexistuje žádná záloha, spuštění funkce REPAIR může opravit nahlášené chyby. Možnost OPRAVIT, která se má použít, je určena na konci seznamu ohlášených chyb. Tato oprava chyb pomocí možnosti REPAIR_ALLOW_DATA_LOSS však může vyžadovat odstranění některých stránek a dat.

Opravu lze provést v rámci transakce uživatele, která uživateli umožní vrátit zpět provedené změny. Pokud jsou opravy vráceny zpět, databáze bude stále obsahovat chyby a musí být obnovena ze zálohy. Po dokončení všech oprav zálohujte databázi.

Sady výsledků

DBCC CHECKTABLE vrátí následující sadu výsledků. Stejná sada výsledků se vrátí, pokud zadáte pouze název tabulky nebo některou z možností.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE vrátí následující sadu výsledků, pokud je zadána možnost ESTIMATEONLY:

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Dovolení

Uživatel musí vlastnit tabulku nebo být členem pevné role serveru správce systému, db_owner pevné databázové role nebo db_ddladmin pevné databázové role.

Příklady

A. Kontrola konkrétní tabulky

Následující příklad zkontroluje integritu datové stránky tabulky HumanResources.Employee v databázi AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Provedení kontroly tabulky s nízkou režií

Následující příklad provádí kontrolu nízké režie tabulky Employee v databázi AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Kontrola konkrétního indexu

Následující příklad zkontroluje konkrétní index získaný přístupem k sys.indexes.

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Viz také