DBCC CHECKDB: MS SQL Server Průvodce stavem databáze

Finanční ztráty průměrně 2.3 milionu dolarů ročně v důsledku ztráty dat, přičemž hlavními příčinami jsou selhání hardwaru a poškození (EMC Corporation)
Míra uzavírání podniků ukazují, že 50 % malých podniků, které zažívají ztrátu dat v důsledku selhání hardwaru, zkrachuje do dvou let, zatímco 94 % podniků s katastrofickou ztrátou dat vůbec nepřežije.
Frekvence poškození dat každoročně postihuje 20 % kriticky důležitých aplikací a způsobuje narušení kontinuity podnikání (výzkum společnosti Gartner)
Poškození hardwaru představuje 67 % všech případů ztráty dat v důsledku havárií pevných disků a selhání systému, přičemž 40 % ztráty dat je přímo přičítáno poruchám hardwaru.
Poškození softwaru costs pohybují se od tisíců do milionů dolarů v závislosti na závažnosti a rozsahu, přičemž 82 % podniků zažilo neplánované výpadky, jejichž hlavní příčinou byla korupce.

1.2 Proč jsou pravidelné zdravotní prohlídky zásadní

Lidé potřebují pravidelné zdravotní prohlídky, aby včas odhalili potenciální nemoci. Podobně i databáze potřebují pravidelné zdravotní kontroly:

Včas odhalte potenciální korupci a neprodleně ji řešte, abyste předešli závažným a rozsáhlým problémům, které by mohly vést ke katastrofálním důsledkům pro podnikání.
Zajistěte, aby databáze fungovala s optimálním výkonem.
Cost Náročnost proaktivních kontrol stavu databáze je mnohem nižší než u reaktivní obnovy dat po havárii databáze.

1.3 Úvod do příkazů pro integritu databáze

SQL Server poskytuje několik vestavěných příkazů pro údržbu stavu databáze, s DBCC CHECKDB sloužící jako most K dispozici je komplexní nástroj pro kontrolu integrity. Tyto příkazy spolupracují na ověření různých aspektů struktury vaší databáze, od jednotlivých tabulek až po konzistenci celé databáze, a tvoří tak kompletní strategii údržby, která udržuje vaše data v bezpečí a přístupná.

2. Co je DBCC CHECKDB

DBCC CHECKDB is SQL ServerHlavní nástroj pro ověřování integrity databáze a identifikaci problémů s poškozením.

Je to příkaz T-SQL, nikoli nástroj s grafickým rozhraním.
Můžete to provést běžnými metodami, jako například SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD atd.

2.1 Co CHECKDB ve vaší databázi vlastně kontroluje

Při spuštění příkazu DBCC CHECKDB provede příkaz několik vrstev ověření napříč strukturou databáze:

Ověření kontrolních součtů stránek k detekci fyzického poškození a problémů s hardwarem
Ověření konzistence indexu zajistit správné načítání dat a provádění dotazů
Kontroly alokační struktury pro potvrzení přesného využití prostoru a alokace stránek
Zkoumání referenční integrity mezi souvisejícími tabulkami a vztahy cizích klíčů
Ověření konzistence systémové tabulky k zajištění SQL ServerInterní metadata zůstávají spolehlivá
Ověření propojení datových stránek pro ověření správné integrity řetězce stránek
Konzistence schématu databáze ověřit definice objektů a závislosti

Tyto komplexní kontroly zahrnují jak uživatelská data, tak i systémové struktury a poskytují tak úplný přehled o stavu vaší databáze.

3. Spuštění příkazu DBCC CHECKDB: Podrobný postup

Předpoklady 3.1

Níže je uveden kontrolní seznam před provedením jakékoli operace DBCC CHECKDB:

Kompletní záloha databáze – Před spuštěním kontrol integrity si vytvořte úplnou zálohu, která slouží jako bezpečnostní síť pro případ zjištění poškození nebo nutnosti opravy.
Správná oprávnění – Pro spuštění příkazů DBCC CHECKDB potřebujete oprávnění sysadmin nebo db_owner.
Dostatečné systémové prostředky:
- Paměť: 25 % velikosti databáze
- Prostor v dočasné databázi: 10–15 % velikosti databáze
- CPU: Dostupnost 50–70 % během údržby
- I/O: Očekávejte náročné operace čtení
Přístupnost databáze – Ověřte, zda je vaše databáze přístupná a není v omezeném stavu, protože CHECKDB vyžaduje přístup pro čtení všech stránek databáze.

3.2 Základní příkaz

Most Základní příkaz DBCC CHECKDB zahrnuje tři běžné varianty:

(1) Zkontrolujte aktuální databázi (bez parametrů):

DBCC CHECKDB

(2) Zkontrolujte databázi podle názvu:

DBCC CHECKDB ('YourDatabaseName')

(3) Zkontrolujte databázi podle ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Tento základní příkaz provede kompletní kontrolu integrity zadané databáze a prozkoumá všechny tabulky, indexy a systémové struktury. U databází se standardními názvy bez mezer můžete uvozovky vynechat. Příkaz bude spuštěn až do dokončení a zobrazí se mu průběžné zprávy a konečné výsledky. Tato základní syntaxe funguje perfektně pro menší databáze nebo v případě, že máte dostatek času na údržbu.

Níže je snímek obrazovky se spuštěním DBCC CHECKDB v SQL Server Management Studio (SSMS):

3.3 Kompletní možnosti

Níže jsou uvedeny kompletní možnosti pro DBCC CHECKDB:

Kategorie	Volba	Popis	Příklad DBCC CHECKDB
Možnosti opravy	`REPAIR_REBUILD`	Opravy bez ztráty dat (např. přestavba indexů)	`DBCC CHECKDB ('MyDB', REPAIR_REBUILD)`
	`REPAIR_FAST`	Žádná oprava. Pouze zpětná kompatibilita.	`DBCC CHECKDB ('MyDB', REPAIR_FAST)`
	`REPAIR_ALLOW_DATA_LOSS`	Opraví všechny chyby (může způsobit ztrátu dat)	`DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)`
Řízení rozsahu	`NOINDEX`	Přeskočí kontroly neklastrovaných indexů	`DBCC CHECKDB ('LargeDB', NOINDEX)`
	`PHYSICAL_ONLY`	Kontroluje pouze integritu fyzického úložiště (stránky/záznamy)	`DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)`
	`DATA_PURITY`	Kontroluje logické chyby v hodnotách sloupců (např. neplatná data)	`DBCC CHECKDB ('OldDB', DATA_PURITY)`
	`EXTENDED_LOGICAL_CHECKS`	Hloubkové logické kontroly (indexované pohledy, XML/prostorové indexy)	`DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)`
Řízení výstupu	`ALL_ERRORMSGS`	Zobrazuje všechny chyby (výchozí: 200 na objekt)	`DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)`
Řízení výstupu	`NO_INFOMSGS`	Skrývá informační zprávy	`DBCC CHECKDB ('MyDB', NO_INFOMSGS)`
Výkon	`TABLOCK`	Používá zámky tabulek (snižuje využití TempDB, ale blokuje zápisy)	`DBCC CHECKDB ('BigDB', TABLOCK)`
Výkon	`MAXDOP = number`	Přepíše nastavení paralelismu	`DBCC CHECKDB ('MyDB', MAXDOP = 2)`
Užitečnost	`ESTIMATEONLY`	Odhaduje potřebný prostor v dočasné databázi. (bez skutečné kontroly)	`DBCC CHECKDB ('MyDB', ESTIMATEONLY)`

4. Pochopení vašich výsledků

Funkce DBCC CHECKDB vygeneruje různé výsledky v závislosti na tom, zda se její provedení úspěšně dokončí, či nikoli. Vysvětlíme si je podrobněji.

4.1 Provedení příkazu CHECKDB bylo úspěšně dokončeno

Pokud se spuštění příkazu DBCC CHECKDB úspěšně dokončí, zobrazí se různé typy výsledků v závislosti na stavu databáze.

4.1.1 Nebyly nalezeny žádné problémy

Pokud příkaz DBCC CHECKDB nenajde žádné problémy, zobrazí se výstup podobný tomuto:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Tento výsledek naznačuje, že vaše databáze si zachovává perfektní integritu napříč všemi kontrolovanými strukturami.

4.1.2 Nalezené chyby poškození

Kdykoli příkaz DBCC CHECKDB zjistí chybu poškození, ohlásí chybovou zprávu s následující strukturou:
Průvodce úrovněmi závažnosti:

Úroveň 16–19 XNUMX: Chyby opravitelné uživatelem, často drobné poškození
Úroveň 20–24 XNUMX: Systémové chyby, závažné poškození vyžadující okamžitou pozornost
Úroveň 25: Závažné chyby, databáze může být nepřístupná

Mezi běžné chyby patří:

Chyby kontrolního součtu stránky (zpráva 824)
Chyby alokace (zpráva 8928)
Problémy s konzistencí indexu (zpráva 8964)

Pochopení struktury zprávy pomáhá stanovit priority reakčních akcí a určit vhodné strategie obnovy.

4.1.3 Běžné informační a varovné zprávy

Ne všechny výstupy příkazu DBCC CHECKDB indikují vážné problémy. Může také zobrazit některé informační a varovné zprávy, včetně:

Výpisy z oprav – Zprávy s návrhy opravných příkazů pro řešení drobných problémů
Varování ohledně alokace – Upozornění ohledně alokace prostoru, která neovlivňují přístup k datům
Doporučení pro výkon – Návrhy na údržbu a optimalizaci indexu
Informační oznámení – Obecné stavové zprávy, které nevyžadují okamžitou akci

Tyto zprávy poskytují cenné pokyny k údržbě a zároveň rozlišují mezi kritickým poškozením vyžadujícím okamžitý zásah a drobnými problémy, které lze řešit během pravidelných intervalů údržby.

Příklad varovné zprávy:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 Přerušení provádění CHECKDB

Pokud se CHECKDB během svého provádění z různých důvodů přeruší, ohlásí chybovou zprávu a přidá protokol chyb s níže uvedeným stavovým kódem:

Stát	Popis
`0`	Byla vyvolána chyba číslo 8930. To indikuje poškození metadat, které ukončilo příkaz DBCC.
`1`	Byla vyvolána chyba číslo 8967. Došlo k interní chybě DBCC.
`2`	Během opravy databáze v nouzovém režimu došlo k chybě.
`3`	To naznačuje poškození metadat, které ukončilo příkaz DBCC.
`4`	Bylo zjištěno narušení oprávnění k uplatnění nebo přístupu.
`5`	Došlo k neznámé chybě, která ukončila příkaz DBCC.

Příklad chybové zprávy:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Příklad chybového protokolu:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

V takovém případě můžete vyzkoušet alternativní pokročilé možnosti, jako například DataNumen SQL Recovery opravit poškození ve vaší databázi.

5. Oprava chyb způsobených poškozením

5.1 Zálohování a obnovení: Nejbezpečnější řešení

Pokud příkaz DBCC CHECKDB identifikuje chyby poškození, představuje obnovení z čisté zálohy nejbezpečnější a nejspolehlivější metodu.ost spolehlivé řešení. Tento přístup zaručuje integritu dat a zároveň eliminuje základní příčiny poškození. Před obnovením ověřte integritu zálohy pomocí OBNOVIT POUZE OVĚŘENÍ příkazy a zvažte možnosti obnovy v čase, abyste minimalizovali ztrátu dat. Zdokumentujte podrobnosti o poškození pro analýzu hlavní příčiny, protože problémy s hardwarem nebo softwarové chyby mohou vyžadovat zvláštní pozornost, aby se zabránilo jejich opakování.

5.2 Řešení poškození na úrovni stránky

V případě izolovaného poškození stránky, které ovlivňuje malé části dat, SQL Server Enterprise Edition nabízí funkce pro obnovu stránek, které opravují konkrétní poškozené stránky bez nutnosti úplné obnovy databáze. Tato pokročilá technika vyžaduje model úplné obnovy a aktuální zálohy protokolů.

Postup obnovy stránky krok za krokem:

Identifikujte poškozenou stránku z chybové zprávy CHECKDB (např. stránka 1:256)
Vytvořte si aktuální zálohu protokolu pro zachycení nedávných transakcí:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

Obnovte poškozenou stránku z most nedávná úplná záloha:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

Použít rozdílovou zálohu (Pokud je k dispozici):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

Použít všechny zálohy protokolů v pořadí, včetně právě vytvořeného:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

Vytvořte finální zálohu protokolu a obnovte jej pro aktualizaci stránky:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternativa pro nekritická data: Pokud poškození ovlivní nekritická data, můžete před obnovením poškozených struktur exportovat nedotčené řádky do nových tabulek:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Rychlé opravy poškození indexu

Poškození indexu často dobře reaguje na operace obnovy, které znovu vytvářejí struktury indexů bez ovlivnění podkladových dat tabulky:

ALTER INDEX ALL ON YourTable REBUILD

Tento přístup funguje obzvláště dobře pro poškození indexů bez klastrů, protože při opětovném sestavení se regenerují stránky indexu z dat zdrojových tabulek, čímž se efektivně eliminuje poškození a zároveň se zachovají všechny původní informace.

6. Použijte REPAIR_REBUILD a REPAIR_ALLOW_DATA_LOSS

Pokud všechny předchozí metody selžou nebo nejsou proveditelné, můžete k opravě databáze použít možnosti REPAIR_REBUILD a REPAIR_ALLOW_DATA_LOSS.

6.1 OPRAVA_PŘESTAVBA (Bezpečnější varianta):

Použij pro: Poškození indexu a drobné chyby v alokaci
Bezpečnost dat: Pokusy o opravu poškození bez smazání dat
Úroveň rizika: Nízká – neočekává se žádná ztráta dat
Typické scénáře: Poškození neklastrovaného indexu, drobné problémy s metadaty
Příklad příkazu: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 OPRAVA_POVOLENÍ_ZTRÁTY_DAT (Poslední možnost):

Použij pro: Závažné poškození, když zálohy nejsou k dispozici
Bezpečnost dat: Může smazat poškozená data pro obnovení funkčnosti databáze
Úroveň rizika: Vysoká – možná trvalá ztráta dat
Typické scénáře: Poškození stránky, poškození systémové tabulky, chyby v alokačním řetězci
Příklad příkazu: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Nejlepší postupy pro tyto možnosti:

Vždy otestujte opravné operace na kopiích databáze, pokud je to možné
Vždy zálohovat před spuštěním těchto možností
Zdokumentujte všechny změny pro účely dodržování předpisů a řešení problémů
Nastavení databáze do režimu pro jednoho uživatele před zahájením oprav

Normálně bychom se měli snažit OPRAVA_PŘESTAVBA možnost jako první. Pokud se to nepodaří, zkuste to REPAIR_ALLOW_DATA_LOSS volba.

6.4 Výsledky REPAIR_ALLOW_DATA_LOSS

6.4.1 Oprava úspěšná se ztrátou dat

Někdy REPAIR_ALLOW_DATA_LOSS Možnost bude úspěšná, ale některá data jsouost po opravě.

Níže uvádíme několik vzorových zpráv:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Je to proto, že DBCC CHECKDB opravuje databázi opuštěním některých poškozených záznamů, ale ve skutečnosti most z nich lze stále získat zpět prostřednictvím DataNumen SQL Recovery.

Ukázkové soubory:

SQL Server verze	Poškozený soubor MDF	Soubor MDF opraven DataNumen SQL Recovery
SQL Server 2014	Chyba10_1.mdf (Zpráva 8909 následovaná zprávou 8939) (600 záznamůost s REPAIR_ALLOW_DATA_LOSS)	Chyba10_1_fixed.mdf (Žádný záznamost)
SQL Server 2014	Chyba10_2.mdf (Zpráva 8909 následovaná zprávou 8939) (6000 záznamů (50 %) lost s REPAIR_ALLOW_DATA_LOSS)	Chyba10_2_fixed.mdf (Pouze 100 záznamůost)
SQL Server 2014	Error7 MDF (100 záznamůost s REPAIR_ALLOW_DATA_LOSS)	Chyba7_fixed.mdf (Pouze jeden záznamost)

6.4.2 Oprava selže – zvažte profesionální řešení

If REPAIR_ALLOW_DATA_LOSS selže, zobrazí se jedna nebo více chybových zpráv.

Níže uvádíme několik příkladů:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

V těchto případech je nutné použít profesionální řešení, jako např. DataNumen SQL Recovery k opravě vaší databáze.

Ukázkové soubory

SQL Server verze	Poškozený soubor MDF	Soubor MDF opraven DataNumen SQL Recovery
SQL Server 2014	Chyba1_3.mdf (Jednotlivá zpráva 824)	Chyba1_3_fixed.mdf
SQL Server 2014	Chyba1_1.mdf (Neustálé chyby Msg 824)	Chyba1_1 _fixed.mdf
SQL Server 2014	Chyba1_2.mdf ((Zpráva 824 následovaná zprávou 7909)	Chyba1_2_fixed.mdf
SQL Server 2014	Chyba4_1.mdf (Zpráva 8992 následovaná zprávou 3852)	Chyba4_1_fixed.mdf
SQL Server 2014	Chyba4_2.mdf (Zpráva 8992 následovaná zprávou 3852)	Chyba4_2_fixed.mdf
SQL Server 2014	Chyba5.mdf (Zpráva 8945)	Chyba5_fixed.mdf
SQL Server 2014	Chyba6.mdf (Zpráva 2510)	Chyba6_fixed.mdf
SQL Server 2014	Chyba2.mdf (Zpráva 2575)	Chyba2_fixed.mdf
SQL Server 2014	Chyba11.mdf (Zpráva 8905)	Chyba11_fixed.mdf
SQL Server 2014	Chyba3.mdf (Zpráva 5028)	Chyba3_fixed.mdf
SQL Server 2014	Error8 MDF (Zpráva 5125)	Error8 _fixed.mdf
SQL Server 2014	Chyba9.mdf (Zpráva 3313)	Chyba9_fixed.mdf

7. Nejlepší postupy

7.1 Plánování pravidelných operací CHECKDB

Pro kritické produkční databáze implementujte týdenní provádění příkazu DBCC CHECKDB a pro systémy s vysokým počtem transakcí denní kontroly. Naplánujte operace během období s nízkým využitím, abyste minimalizovali dopad na výkon, a zvažte střídání mezi plnými kontrolami a možnostmi PHYSICAL_ONLY na základě velikosti databáze a intervalů údržby. Automatizované plánování prostřednictvím SQL Server Agent zajišťuje konzistentní provádění a zároveň poskytuje centralizované monitorovací a upozorňovací funkce.

7.2 Řízení dopadu na výkon

Operace DBCC CHECKDB spotřebovávají značné množství systémových prostředků, což může ovlivnit souběžnou aktivitu uživatelů. Během kontrol sledujte využití CPU, spotřebu paměti a diskové I/O operace, abyste pochopili vzorce dopadu na výkon. Pro rutinní kontroly zvažte použití možností NOINDEX a úplné ověření vyhraďte pro měsíční údržbová okna. Implementujte prodloužení časového limitu dotazů a strategie komunikace s uživateli pro správu očekávání během období kontroly integrity.

7.3 Plánování údržbového okna

Koordinujte plánování DBCC CHECKDB s dalšími aktivitami údržby, jako jsou zálohovací operace, opětovné sestavení indexů a aktualizace statistik. Vyhněte se překrývání operací náročných na zdroje, které by mohly způsobit snížení výkonu nebo problémy s časovým limitem. Naplánujte okna údržby na základě prognóz růstu velikosti databáze a zajistěte dostatek času pro úplné ověření integrity s rostoucími objemy dat.

7.4 Automatizované monitorování a upozorňování

Konfigurace SQL Server Upozornění agentů, aby okamžitě upozornili administrátory, když DBCC CHECKDB identifikuje poškození. Implementujte řešení pro analýzu protokolů, která extrahují a kategorizují výsledky kontrol integrity, což umožňuje analýzu trendů a proaktivní identifikaci problémů. Vytvořte eskalační postupy, které definují časové rámce odezvy a odpovědné osoby pro různé úrovně závažnosti poškození.

8. DBCC CHECKTABLE: Lehká alternativa

8.1 Kdy použít CHECKTABLE místo CHECKDB

DBCC CHECKTABLE poskytuje cílenou kontrolu integrity jednotlivých tabulek, což je ideální pro tarřešení problémů a údržba specifických databázových objektů. CHECKTABLE použijte při zkoumání problémů s výkonem konkrétních tabulek, ověřování kritických obchodních tabulek mezi úplnými kontrolami databáze nebo v případech, kdy časová omezení brání úplnému ověřování databáze. Tento přístup se ukazuje jako obzvláště cenný u velkých databází, kde plné operace CHECKDB překračují dostupná okna údržby.

8.2 Syntaxe a příklady DBCC CHECKTABLE

Základní příkaz CHECKTABLE tarzískává konkrétní tabulky:

DBCC CHECKTABLE('YourTable')

Stejně jako CHECKDB, i CHECKTABLE podporuje různé možnosti včetně NOINDEX pro optimalizaci výkonu a parametrů opravy pro řešení poškození. Můžete také zadat názvy schémat pro přesnou identifikaci tabulek:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Toto tarZavedený přístup umožňuje detailní ověření integrity a zároveň zachování výkonu systému během pracovní doby.

8.3 Výhody výkonu pro velké databáze

Operace CHECKTABLE se dokončují výrazně rychleji než úplné kontroly databáze, což umožňuje častější ověřování integrity kritických tabulek. Tento přístup umožňuje denní ověřování důležitých obchodních tabulek a zároveň rezervuje komplexní operace CHECKTABLE pro týdenní nebo měsíční plány. Díky snížené spotřebě zdrojů je CHECKTABLE vhodný pro provoz v produkčním prostředí s minimálním dopadem na uživatele.

9. Když CHECKDB selže

Příkaz DBCC CHECKDB selže v různých scénářích, včetně:

Provedení DBCC CHECKDB ukončí se abnormálně
Provedení příkazu DBCC CHECKDB se úspěšně dokončí, ale možnosti opravy selže oprava databáze.

V těchto scénářích potřebujeme profesionálnější nástroj, který nám pomůže opravit poškození v databázi.

9.1 Úvod do DataNumen SQL Recovery

DataNumen SQL Recovery nabízí pokročilejší funkce:

Nejlepší míra zotavení v průmyslu.
Obnovte silně poškozené soubory databáze.
Obnovte všechny databázové objekty, včetně tabulek, indexů, zobrazení, triggerů, pravidel a výchozích hodnot.
Obnovte uložené procedury, skalární funkce, vložené funkce s hodnotou tabulky a vícepříkazové funkce s hodnotou tabulky.
Obnovte trvale smazané záznamy.
Dešifrovat šifrované objekty v SQL Server databází.
Dávková oprava souborů MDF.
Komplexní možnosti oprav.
Pokročilé protokolování a hlášení.
Podpora pro všechny SQL Server verze.
Dostupnost technické podpory
Pravidelné aktualizace a vylepšení

9.2 Porovnání míry úspěšnosti

Úspěšnost zotavení se výrazně liší:

DBCC CHECKDB a CHECKTABLEC: 1.27% průměrná míra obnovy
DataNumen: 92.6% míra zotavení

Níže je kompletní konkurenční srovnání:

9.3 Zotavení ze závažné korupce

Pokročilé možnosti pro těžké případy:

Obnova z fyzicky poškozeného úložiště
Obnova z naformátovaných disků nebo havarovaných systémů
Obnova z diskových obrazů, záložních souborů, diskových souborů virtuálního stroje, temparary soubory atd.

9.4 Kdy zvážit profesionální řešení

Žádná nedávná záloha k dispozici
DBCC CHECKDB selže
Závažné scénáře korupce
Zpracování kritických obchodních dat
Když je čas kritický
Když je nezbytná maximální regenerace

10. Časté dotazy

10.1 Základní otázky týkající se používání

Otázka: Jak často mám spouštět příkaz DBCC CHECKDB?

A: Pro kritické produkční databáze spusťte CHECKDB týdně. Pro systémy s vysokým počtem transakcí zvažte denní kontroly s použitím možnosti PHYSICAL_ONLY a úplné kontroly týdně. Vývojové databáze lze kontrolovat měsíčně.

Otázka: Mohu spustit příkaz DBCC CHECKDB v aktivní produkční databázi?

A: Ano, DBCC CHECKDB může běžet na online databázích bez blokování uživatelů. Spotřebovává však značné množství zdrojů, proto jej naplánujte na období s nízkou aktivitou a sledujte výkon systému.

Otázka: Jaký je rozdíl mezi CHECKDB a CHECKTABLE?

A: CHECKTABLE prozkoumá celou databázi, zatímco CHECKTABLE se zaměřuje na jednotlivé tabulky. Pro tarřešení problémů nebo když potřebujete zkontrolovat konkrétní tabulky bez prohledávání celé databáze.

10.2 Otázky týkající se výkonu a zdrojů

Otázka: Proč trvá operaci DBCC CHECKDB v mé rozsáhlé databázi tak dlouho?

A: Doba trvání CHECKDB závisí na velikosti databáze, výkonu hardwaru a použitých možnostech. Pro rychlejší kontroly použijte PHYSICAL_ONLY nebo NOINDEX pro přeskočení neklastrovaných indexů. Zvažte spuštění během údržbových oken s vyhrazenými zdroji.

Otázka: Kolik místa v dočasné databázi potřebuje CHECKDB?

A: Obecně platí, že během operací CHECKDB alokujte pro dočasnou databázi 10–15 % velikosti databáze. Pro přesné odhady použijte možnost ESTIMATEONLY: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

Otázka: Mohu zrušit spuštěnou operaci CHECKDB?

A: Ano, příkaz CHECKDB můžete zrušit pomocí příkazu KILL na ID relace. Zrušení však neposkytuje žádné informace o integritě databáze a budete ho muset později spustit znovu.

10.3 Otázky týkající se ošetření chyb

Q: CHECKDB nalezl chyby – mám panikařit?

A: Nepanikařte, ale jednejte rychle. Nejprve zjistěte, zda se příkaz CHECKDB úspěšně dokončil, ale zjistil poškození, nebo zda se samotný příkaz CHECKDB nepodařilo spustit. Zkontrolujte, zda chyby ovlivňují pouze neklastrované indexy (méně kritické) nebo tabulková data (závažnější).

Otázka: Kdy mám použít REPAIR_ALLOW_DATA_LOSS?

A: Pouze jako absolutně poslední možnost, pokud nemáte žádné použitelné zálohy a ztráta dat je přijatelná ve srovnání s úplnou ztrátou databáze. Vždy se nejprve pokuste obnovit data ze zálohy, protože opravné operace mohou způsobit trvalou ztrátu dat.

Otázka: Co znamená „chyby konzistence v databázi“ vs. „chyby alokace“?

A: Chyby alokace ovlivňují, jak SQL Server sleduje využití místa na disku, zatímco chyby konzistence indikují problémy s daty nebo indexovými strukturami. Obě vyžadují pozornost, ale chyby konzistence obvykle přímočařeji ovlivňují přístupnost dat.

10.4 Otázky týkající se zálohování a obnovy

Otázka: Mám spustit CHECKDB na svých zálohách?

A: Rozhodně! Po obnovení záloh na testovací servery spusťte příkaz CHECKDB. Tím se ověří integrita zálohy a zajistí se skutečná obnova po poškození. Pokud je to možné, tento proces automatizujte.

Otázka: Moje záloha je také poškozená – co teď?

A: Zkoušejte starší zálohy, dokud nenajdete čistou. Pokud žádné čisté zálohy neexistují, zvažte profesionální řešení pro obnovu, jako je DataNumen SQL RecoveryZdokumentujte časovou osu korupce, abyste předešli jejímu výskytu v budoucnu.

Otázka: Může obnova stránky opravit poškození bez úplné obnovy databáze?

A: Ano, ale pouze v SQL Server Enterprise Edition s modelem úplné obnovy a aktuálními zálohami protokolů. Obnova stránek funguje pro izolované poškození stránek, ale vyžaduje pečlivé provedení dodržováním správných postupů.

10.5 Otázky k řešení problémů

Otázka: CHECKDB selhává a zobrazuje chyby „nedostatek místa“ – co s tím mám dělat?

A: Uvolněte místo v dočasné databázi, přesuňte ji do rychlejšího úložiště nebo použijte volbu TABLOCK ke snížení využití dočasné databáze. Zvažte spuštění CHECKDB s parametrem NOINDEX nebo PHYSICAL_ONLY pro snížení požadavků na zdroje.

Otázka: Jak z výstupu CHECKDB zjistím, která tabulka je poškozená?

A: Hledejte v chybových zprávách čísla „ID objektu“ a poté použijte: SELECT OBJECT_NAME(object_id) najít názvy tabulek. Chybové zprávy také obsahují čísla stránek a slotů pro přesnou identifikaci umístění.

Otázka: Mohou problémy s hardwarem způsobit, že CHECKDB bude hlásit falešně pozitivní výsledky?

A: Ano, selhávající hardware (zejména úložiště) může způsobovat občasné poškození, které se objevuje a mizí mezi spuštěními příkazu CHECKDB. Pokud jsou chyby nekonzistentní, prozkoumejte svůj I/O subsystém a spusťte několik kontrol, abyste potvrdili vzorce.

10.6 Pokročilé otázky týkající se konfigurace

Otázka: Které trasovací příznaky mohou zlepšit výkon CHECKDB?

A: Trasovací příznak 2562 může zlepšit výkon spuštěním příkazu CHECKDB jako jedné dávky. Trasovací příznak 2549 je užitečný, když jsou soubory databáze na samostatných discích. Používejte je opatrně a nejprve je otestujte v neprodukčním prostředí.

Otázka: Jak automatizuji monitorování a upozorňování CHECKDB?

A: Použijte SQL Server Upozornění agentů na chyby s čísly 8930, 8939 a další. Implementujte analýzu protokolů pro extrakci výsledků CHECKDB a vytvářejte oznámení o všech zjištěních poškození. Zvažte použití frameworků pro řešení údržby, jako jsou skripty Oly Hallengren.

Otázka: Mám použít možnost EXTENDED_LOGICAL_CHECKS?

A: Pouze pokud máte podezření na složité logické poškození a máte dostatečné režijní náklady na výkon. Tato možnost provádí dodatečné kontroly indexovaných zobrazení, XML indexů a prostorových indexů, ale výrazně zvyšuje dobu provádění.

11. závěr

11.1 Shrnutí klíčových bodů

11.1.1 Shrnutí základních příkazů DBCC CHECKDB

Zvládněte základní syntaxi DBCC CHECKDB pro komplexní kontrolu databáze, využijte možnosti NOINDEX a PHYSICAL_ONLY pro optimalizaci výkonu a pochopte CHECKTABLE pro tarověření tabulky get. Tyto základní příkazy tvoří základ proaktivní údržby databáze, umožňují včasnou detekci poškození a systematické sledování integrity.

11.1.2 Připomenutí klíčových osvědčených postupů

Před spuštěním kontrol integrity vždy udržujte aktuální zálohy, naplánujte pravidelné operace CHECKDB na základě kritickosti databáze a implementujte automatizované monitorování pro okamžitá upozornění na poškození. Nezapomeňte, že prevence prostřednictvím pravidelného monitorování předčí reaktivní přístupy a profesionální řešení pro obnovu poskytují cenné možnosti zálohování, když se standardní nástroje ukážou jako nedostatečné.

11.2 Kdy použít DBCC CHECKDB vs. pokročilá řešení

Pro rutinní monitorování integrity a řešení drobných poškození používejte DBCC CHECKDB, zatímco pro závažné scénáře poškození nad rámec vestavěných možností opravy si vyhraďte profesionální nástroje pro obnovu. Rozhodovací rámec by měl zohledňovat dostupnost záloh, kritickost dat, časová omezení a závažnost poškození. Úspěšní správci databází kombinují pravidelné monitorování CHECKDB s komplexními strategiemi zálohování a znalostí pokročilých možností obnovy, když se standardní přístupy ukážou jako nedostatečné.

11.3 Rychlý denní kontrolní seznam stavu pro správce databází

Kromě spuštění DBCC CHECKDB udržujte optimální stav databáze pomocí těchto základních každodenních postupů:

1. Ověřte integritu zálohy

Potvrzení úspěšného dokončení plánovaných záloh
Pro ověření čitelnosti zálohy použijte RESTORE VERIFYONLY.
Zajistěte synchronizaci a přístupnost kopií mimo pracoviště

Můžete také získat další informace od náš komplexní průvodce SQL Server zálohování.

2. Zkontrolujte stav konzistence

Zkontrolujte automatizované výsledky DBCC CHECKDB z nočních běhů
monitor SQL Server protokoly chyb pro varování před poškozením
Okamžitě prošetřete jakékoli narušení integrity

3. Monitorujte stav serveru

Zkontrolujte metriky CPU, paměti a disku I/O
Ověření dostupnosti prostoru v dočasné databázi
Identifikace blokovaných procesů a dlouho běžících dotazů

4. Sledování aktivity zablokování

Prohlédněte si grafy zablokování z událostí stavu systému
Identifikujte problematické dotazy a optimalizujte je s vývojovými týmy
Sledování počtu obětí deadlocků a jejich dopadu na podnikání

Důležitá připomenutí

Vyhněte se častému zmenšování databáze – zvyšuje fragmentaci a snižuje výkon. Zmenšujte data pouze po smazání většího množství dat, když je to skutečně nutné.
Automatizace monitorovacích úloh použitím SQL Server Úlohy agentů nebo plány údržby s upozorněními na kritické problémy.
Testovací postupy pro zotavení z havárie týdně, aby se zajistila obnovitelnost záloh a dosažitelnost cílů obnovy.

Kombinací tohoto denního kontrolního seznamu s pravidelnými operacemi DBCC CHECKDB vytvoříte komplexní ochranu pro vaše databázové prostředí prostřednictvím proaktivního monitorování a rychlé reakce na problémy.

12. Reference

Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server DokumentaceSpolečnost Microsoft.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
Microsoft Learn. „Řešení problémů s chybami konzistence databáze hlášenými příkazem DBCC CHECKDB.“ SQL Server DokumentaceSpolečnost Microsoft.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors

DBCC CHECKDB: Kompletní průvodce MS SQL Server Stav databáze (2025)

1. Důležitost SQL Server Stav databáze

1.1 Co je poškození databáze Costs Podniky