DBCC CHECKDB: Kompletný sprievodca MS SQL Server Stav databázy (2025)

Poškodenie databázy je každý SQL Server nočná mora správcu. Keď sa kritické obchodné údaje stanú nedostupnými alebo nespoľahlivými, cost môže byť zničujúce. Táto komplexná príručka obsahuje všetko, čo potrebujete vedieť o používaní DBCC CHECKDB na udržanie stavu databázy a predchádzanie poškodeniu, a tiež pokročilé riešenia obnovy pre prípady, keď štandardné nástroje nestačia.

1. Dôležitosť SQL Server Stav databázy

1.1 Čo je poškodenie databázy Costs Firmy

Dnes, most Firmy ukladajú svoje kritické údaje do databáz. Keď dôjde k poškodeniu databázy, následky sú katastrofálne:

• Finančné straty priemerne 2.3 milióna dolárov ročne v dôsledku straty údajov, pričom hlavnými príčinami sú zlyhanie hardvéru a poškodenie (EMC Corporation)
• Miera zatvárania podnikov ukazujú, že 50 % malých podnikov, ktoré zažívajú stratu údajov v dôsledku zlyhania hardvéru, skrachuje do dvoch rokov, zatiaľ čo 94 % podnikov s katastrofickou stratou údajov vôbec neprežije.
• Frekvencia poškodenia údajov každoročne postihuje 20 % kriticky dôležitých aplikácií a spôsobuje narušenie kontinuity podnikania (výskum spoločnosti Gartner)
• Poškodenie hardvéru predstavuje 67 % všetkých prípadov straty dát v dôsledku havárií pevných diskov a zlyhaní systému, pričom 40 % straty dát sa priamo pripisuje poruchám hardvéru.
• Poškodenie softvéru costs pohybujú sa od tisícov do miliónov dolárov v závislosti od závažnosti a rozsahu, pričom 82 % podnikov zažilo neplánované výpadky, ktorých hlavnou príčinou bola korupcia

1.2 Prečo sú pravidelné zdravotné prehliadky kritické

Ľudia potrebujú pravidelné zdravotné prehliadky, aby včas odhalili potenciálne choroby. Podobne aj databázy potrebujú pravidelné zdravotné prehliadky:

1. Včas odhaliť potenciálnu korupciu a promptne ju riešiť, čím predídete závažnému a rozsiahlemu rozšíreniu problémov, ktoré by mohli viesť ku katastrofálnym následkom pre podnikanie.
2. Zabezpečte, aby databáza fungovala s optimálnym výkonom.
3. Cost Náročnosť proaktívnych kontrol stavu databázy je oveľa nižšia ako náročnosť reaktívnej obnovy dát po havárii databázy.

1.3 Úvod do príkazov integrity databázy

SQL Server poskytuje niekoľko vstavaných príkazov na udržiavanie stavu databázy, s DBCC CHECKDB slúžiaci ako most K dispozícii je komplexný nástroj na kontrolu integrity. Tieto príkazy spolupracujú na overení rôznych aspektov štruktúry vašej databázy, od jednotlivých tabuliek až po konzistenciu celej databázy, a vytvárajú tak kompletnú stratégiu údržby, ktorá udržiava vaše údaje v bezpečí a prístupné.

2. Čo je DBCC CHECKDB

DBCC CHECKDB is SQL Serverhlavný nástroj na overovanie integrity databázy a identifikáciu problémov s poškodením.

• Je to príkaz T-SQL, nie nástroj s grafickým rozhraním.
• Môžete to vykonať bežnými metódami, ako napríklad SQL Server Manažérske štúdio (SSMS), SQL Server Agent, SQLCMD atď.

2.1 Čo vlastne CHECKDB kontroluje vo vašej databáze

Keď spustíte príkaz DBCC CHECKDB, príkaz vykoná viacero overovacích vrstiev v rámci štruktúry databázy:

• Overenie kontrolných súčtov stránok na detekciu fyzického poškodenia a problémov súvisiacich s hardvérom
• Overenie konzistencie indexu zabezpečiť správne načítanie údajov a výkon dotazov
• Kontroly štruktúry alokácie na potvrdenie presného využitia priestoru a pridelenia stránok
• Skúška referenčnej integrity medzi súvisiacimi tabuľkami a vzťahmi cudzích kľúčov
• Overenie konzistencie systémovej tabuľky na zabezpečenie SQL ServerInterné metadáta zostávajú spoľahlivé
• Overenie prepojenia dátových stránok na potvrdenie správnej integrity reťazca stránok
• Konzistencia schémy databázy overiť definície objektov a závislosti

Tieto komplexné kontroly pokrývajú používateľské údaje aj systémové štruktúry a poskytujú úplný prehľad o stave vašej databázy.

3. Spustenie príkazu DBCC CHECKDB: Podrobný postup

Predpoklady 3.1

Nižšie je uvedený kontrolný zoznam pred vykonaním akejkoľvek operácie DBCC CHECKDB:

• Kompletná záloha databázy – Pred spustením kontrol integrity si vytvorte úplnú zálohu ako bezpečnostnú sieť pre prípad zistenia poškodenia alebo potreby opravy.
• Správne povolenia – Na vykonávanie príkazov DBCC CHECKDB potrebujete oprávnenia sysadmin alebo db_owner.
• Dostatočné systémové prostriedky:
  • Pamäť: 25 % veľkosti databázy
  • Priestor v dočasnej databáze: 10 – 15 % veľkosti databázy
  • CPU: Dostupnosť 50 – 70 % počas údržby
  • I/O: Očakávajte rozsiahle operácie čítania
• Prístupnosť databázy – Overte, či je vaša databáza prístupná a nie je v obmedzenom stave, pretože CHECKDB vyžaduje prístup na čítanie všetkých stránok databázy.

3.2 Základný príkaz

Most Základný príkaz DBCC CHECKDB zahŕňa tri bežné variácie:

(1) Skontrolujte aktuálnu databázu (bez parametrov):

DBCC CHECKDB

(2) Skontrolujte databázu podľa názvu:

DBCC CHECKDB ('YourDatabaseName')

(3) Skontrolujte databázu podľa ID:

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

Tento základný príkaz vykoná úplnú kontrolu integrity zadanej databázy, pričom preskúma všetky tabuľky, indexy a systémové štruktúry. V prípade databáz so štandardnými názvami bez medzier môžete úvodzovky vynechať. Príkaz bude spustený až do dokončenia a zobrazí správy o priebehu a konečné výsledky. Táto základná syntax funguje perfektne pre menšie databázy alebo keď máte k dispozícii dostatok času na údržbu.

Nižšie je uvedená snímka obrazovky so spustením DBCC CHECKDB v SQL Server Štúdio pre správu (SSMS):

3.3 Kompletné možnosti

Nižšie sú uvedené kompletné možnosti pre DBCC CHECKDB:

kategórie	voľba	Popis	Príklad DBCC CHECKDB
Možnosti opravy	REPAIR_REBUILD	Opravy bez straty údajov (napr. prestavba indexov)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Žiadna oprava. Iba spätná kompatibilita.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Opraví všetky chyby (môže spôsobiť stratu údajov)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kontrola rozsahu	NOINDEX	Preskočí kontroly neklastrovaných indexov	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Kontroluje iba integritu fyzického úložiska (stránky/záznamy)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Kontroluje logické chyby v hodnotách stĺpcov (napr. neplatné dátumy)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Hlboké logické kontroly (indexované pohľady, XML/priestorové indexy)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Ovládanie výstupu	ALL_ERRORMSGS	Zobrazuje všetky chyby (predvolene: 200 na objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Skryje informačné správy	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
výkon	TABLOCK	Používa zámky tabuliek (znižuje využitie TempDB, ale blokuje zápisy)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Prepíše nastavenia paralelizmu	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Užitočnosť	ESTIMATEONLY	Odhaduje potrebný priestor v dočasnej databáze (bez skutočnej kontroly).	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Pochopenie vašich výsledkov

Príkaz DBCC CHECKDB vygeneruje rôzne výsledky v závislosti od toho, či sa jeho vykonanie úspešne dokončí alebo nie. Vysvetlime si ich podrobnejšie.

4.1 Vykonanie CHECKDB bolo úspešne dokončené

Ak sa vykonanie príkazu DBCC CHECKDB úspešne dokončí, zobrazí sa rôzne typy výsledkov v závislosti od stavu databázy.

4.1.1 Nenašli sa žiadne problémy

Ak príkaz DBCC CHECKDB nenájde žiadne problémy, zobrazí sa 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ýsledok naznačuje, že vaša databáza si zachováva dokonalú integritu vo všetkých kontrolovaných štruktúrach.

4.1.2 Nájdené chyby poškodenia

Vždy, keď DBCC CHECKDB zistí chybu poškodenia, nahlási chybové hlásenie s nasledujúcou štruktúrou:
Sprievodca úrovňou závažnosti:

• Úroveň 16 - 19 XNUMX: Chyby opraviteľné používateľom, často drobné poškodenia
• Úroveň 20 - 24 XNUMX: Systémové chyby, závažné poškodenie vyžadujúce okamžitú pozornosť
• Úroveň 25: Závažné chyby, databáza môže byť neprístupná

Medzi bežné chyby patria:

• Zlyhania kontrolného súčtu stránky (správa 824)
• Chyby prideľovania (správa 8928)
• Problémy s konzistenciou indexu (správa 8964)

Pochopenie štruktúry správy pomáha pri stanovovaní priorít reakcií a určovaní vhodných stratégií obnovy.

4.1.3 Bežné informačné a varovné správy

Nie všetky výstupy príkazu DBCC CHECKDB indikujú vážne problémy. Môže tiež zobraziť niektoré informačné a varovné správy vrátane:

• Výpisy opráv – Správy, ktoré navrhujú príkazy na opravu menších problémov
• Upozornenia na alokáciu – Upozornenia týkajúce sa alokácie priestoru, ktoré neovplyvňujú prístup k údajom
• Odporúčania pre výkon – Návrhy na údržbu a optimalizáciu indexu
• Informačné oznámenia – Všeobecné stavové správy, ktoré nevyžadujú okamžitú akciu

Tieto správy poskytujú cenné pokyny pre údržbu a zároveň rozlišujú medzi kritickým poškodením vyžadujúcim okamžitý zásah a menej závažnými problémami, ktoré je možné riešiť počas bežných intervalov údržby.

Príklad varovnej sprá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 Prerušenia vykonávania CHECKDB

Ak sa CHECKDB počas vykonávania z rôznych dôvodov preruší, nahlási chybové hlásenie a pridá protokol chyby s nasledujúcim stavovým kódom:

stáť	Popis
0	Bola vyvolaná chyba číslo 8930. Toto číslo označuje poškodenie metadát, ktoré ukončilo príkaz DBCC.
1	Bola vyvolaná chyba číslo 8967. Vyskytla sa interná chyba DBCC.
2	Počas opravy databázy v núdzovom režime došlo k chybe.
3	Toto indikuje poškodenie metadát, ktoré ukončilo príkaz DBCC.
4	Bolo zistené porušenie tvrdenia alebo prístupu.
5	Vyskytla sa neznáma chyba, ktorá ukončila príkaz DBCC.

Príklad chybového hlásenia:

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.

or

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

Prí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 takom prípade môžete vyskúšať alternatívne pokročilé možnosti, ako napríklad DataNumen SQL Recovery opraviť poškodenie vo vašej databáze.

5. Oprava chýb spôsobených poškodením

5.1 Zálohovanie a obnovenie: Najbezpečnejšie riešenie

Keď príkaz DBCC CHECKDB identifikuje chyby poškodenia, obnovenie z čistej zálohy predstavuje najbezpečnejšie a najefektívnejšie riešenie.ost spoľahlivé riešenie. Tento prístup zaručuje integritu údajov a zároveň eliminuje základné príčiny poškodenia. Pred obnovením overte integritu zálohy pomocou OBNOVIŤ LEN VERIFY príkazy a zvážte možnosti obnovy v čase, aby ste minimalizovali stratu údajov. Zdokumentujte podrobnosti o poškodení pre analýzu základnej príčiny, pretože problémy s hardvérom alebo softvérové ​​chyby môžu vyžadovať dodatočnú pozornosť, aby sa predišlo opakovaniu.

5.2 Riešenia poškodenia na úrovni stránky

V prípade izolovaného poškodenia stránky ovplyvňujúceho malé časti údajov, SQL Server Enterprise Edition ponúka možnosti obnovy stránok, ktoré opravujú konkrétne poškodené stránky bez úplnej obnovy databázy. Táto pokročilá technika vyžaduje model úplnej obnovy a aktuálne zálohy protokolov.

Postup obnovy stránky krok za krokom:

1. Identifikujte poškodenú stránku z chybového hlásenia CHECKDB (napr. strana 1:256)
2. Vytvorte si aktuálnu zálohu protokolu na zachytenie nedávnych transakcií:

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

3. Obnoviť poškodenú stránku z most nedávna úplná záloha:

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

4. Použiť diferenciálnu zálohu (Ak je k dispozícii):

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

5. Použiť všetky zálohy protokolov postupne, vrátane práve vytvorené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'

6. Vytvorte záverečnú zálohu a obnovu protokolu aktuálna stránka:

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

Alternatíva pre nekritické údaje: Ak poškodenie ovplyvní nekritické údaje, môžete pred obnovením poškodených štruktúr exportovať neovplyvnené riadky do nových tabuliek:

-- 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 Rýchle opravy poškodenia indexu

Poškodenie indexu často dobre reaguje na operácie prestavby, ktoré znovu vytvoria štruktúry indexu bez ovplyvnenia podkladových údajov tabuľky:

ALTER INDEX ALL ON YourTable REBUILD

Tento prístup funguje obzvlášť dobre pri poškodení neklastrovaných indexov, pretože opätovné zostavenie regeneruje stránky indexu z údajov zdrojových tabuliek, čím efektívne eliminuje poškodenie a zároveň zachováva všetky pôvodné informácie.

6. Použite REPAIR_REBUILD a REPAIR_ALLOW_DATA_LOSS

Ak všetky predchádzajúce metódy zlyhajú alebo nie sú uskutočniteľné, môžete na opravu databázy použiť možnosti REPAIR_REBUILD a REPAIR_ALLOW_DATA_LOSS.

6.1 OPRAVA_PRESTAVBA (Bezpečnejšia možnosť):

• Použiť pre: Poškodenie indexu a menšie chyby v alokácii
• Bezpečnosť údajov: Pokúša sa o opravu poškodenia bez vymazania údajov
• Úroveň rizika: Nízka – neočakáva sa žiadna strata údajov
• Typické scenáre: Poškodenie neklastrovaného indexu, menšie problémy s metadátami
• Príklad príkazu: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 OPRAVA_POVOLENIE_STRATY_ÚDAJOV (Posledná možnosť):

• Použiť pre: Závažné poškodenie, keď zálohy nie sú k dispozícii
• Bezpečnosť údajov: Môže odstrániť poškodené údaje, aby sa obnovila funkčnosť databázy
• Úroveň rizika: Vysoká – možná trvalá strata údajov
• Typické scenáre: Poškodenie stránky, poškodenie systémovej tabuľky, chyby v alokačnom reťazci
• Príklad príkazu: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Najlepšie postupy pre tieto možnosti:

• Vždy otestujte opravné operácie na kópiách databázy, ak je to možné
• Vždy zálohovať pred spustením týchto možností
• Zdokumentujte všetky zmeny na účely dodržiavania predpisov a riešenia problémov
• Nastavenie databázy do režimu pre jedného používateľa pred začatím opráv

Normálne by sme sa mali pokúsiť OPRAVA_PRESTAVBA najprv možnosť. Ak to zlyhá, skúste to REPAIR_ALLOW_DATA_LOSS možnosť.

6.4 Výsledky funkcie OPRAVA_POVOLENIE_STRATY_ÚDAJOV

6.4.1 Oprava úspešná so stratou údajov

Niekedy REPAIR_ALLOW_DATA_LOSS možnosť bude úspešná, ale niektoré údaje súost po oprave.

Nižšie sú uvedené niektoré vzorové správy:

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 preto, lebo DBCC CHECKDB opravuje databázu tak, že opúšťa niektoré poškodené záznamy, ale v skutočnosti most z nich sa stále dajú získať späť prostredníctvom DataNumen SQL Recovery.

Ukážkové súbory:

SQL Server verzia	Poškodený súbor MDF	Súbor MDF opravený DataNumen SQL Recovery
SQL Server 2014	Chyba10_1.mdf (Správa 8909, po ktorej nasleduje správa 8939) (600 záznamovost s REPAIR_ALLOW_DATA_LOSS)	Chyba10_1_fixed.mdf (Žiadny záznamost)
SQL Server 2014	Chyba10_2.mdf (Správa 8909 nasledovaná správou 8939) (6000 záznamov (50 %) lost s REPAIR_ALLOW_DATA_LOSS)	Chyba10_2_fixed.mdf (Iba 100 záznamovost)
SQL Server 2014	error7MDF (100 záznamovost s REPAIR_ALLOW_DATA_LOSS)	Chyba7_fixed.mdf (Iba jeden záznamost)

6.4.2 Oprava zlyhá – zvážte profesionálne riešenie

If REPAIR_ALLOW_DATA_LOSS zlyhá, zobrazí sa jedno alebo viacero chybových hlásení.

Nižšie uvádzame niekoľko príkladov:

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 takýchto prípadoch je potrebné použiť profesionálne riešenie, ako napr. DataNumen SQL Recovery na opravu vašej databázy.

Vzorové súbory

SQL Server verzia	Poškodený súbor MDF	Súbor MDF opravený DataNumen SQL Recovery
SQL Server 2014	Chyba1_3.mdf (Jednotlivá správa 824)	Chyba1_3_fixed.mdf
SQL Server 2014	Chyba1_1.mdf (Nepretržité chyby Msg 824)	Chyba1_1_fixed.mdf
SQL Server 2014	Chyba1_2.mdf ((Správa 824 nasledovaná správou 7909)	Chyba1_2_fixed.mdf
SQL Server 2014	Chyba4_1.mdf (Správa 8992, po ktorej nasleduje správa 3852)	Chyba4_1_fixed.mdf
SQL Server 2014	Chyba4_2.mdf (Správa 8992, po ktorej nasleduje správa 3852)	Chyba4_2_fixed.mdf
SQL Server 2014	Chyba5.mdf (Správa 8945)	Chyba5_fixed.mdf
SQL Server 2014	Chyba6.mdf (Správa 2510)	Chyba6_fixed.mdf
SQL Server 2014	Chyba2.mdf (Správa 2575)	Chyba2_fixed.mdf
SQL Server 2014	Chyba11.mdf (Správa 8905)	Chyba11_fixed.mdf
SQL Server 2014	Chyba3.mdf (Správa 5028)	Chyba3_fixed.mdf
SQL Server 2014	error8MDF (Správa 5125)	error8_fixed.mdf
SQL Server 2014	Chyba9.mdf (Správa 3313)	Chyba9_fixed.mdf

7. Najlepšie postupy

7.1 Plánovanie pravidelných operácií CHECKDB

Implementujte týždenné vykonávanie príkazu DBCC CHECKDB pre kritické produkčné databázy s dennými kontrolami pre systémy s vysokým počtom transakcií. Naplánujte operácie počas období s nízkou mierou využívania, aby ste minimalizovali vplyv na výkon, a zvážte striedanie medzi úplnými kontrolami a možnosťami PHYSICAL_ONLY na základe veľkosti databázy a okien údržby. Automatizované plánovanie prostredníctvom SQL Server Agent zabezpečuje konzistentné vykonávanie a zároveň poskytuje centralizované monitorovacie a upozorňovacie funkcie.

7.2 Riadenie vplyvu na výkonnosť

Operácie DBCC CHECKDB spotrebúvajú značné množstvo systémových prostriedkov, čo môže mať vplyv na súbežnú aktivitu používateľov. Počas kontrol monitorujte využitie CPU, spotrebu pamäte a vstupno-výstupné operácie na disku, aby ste pochopili vzorce vplyvu na výkon. Zvážte použitie možností NOINDEX pre bežné kontroly a úplné overenie si vyhraďte pre mesačné okná údržby. Implementujte predĺženia časového limitu dotazov a stratégie komunikácie s používateľmi na riadenie očakávaní počas období kontroly integrity.

7.3 Plánovanie údržbového okna

Koordinujte plánovanie DBCC CHECKDB s inými aktivitami údržby, ako sú zálohovacie operácie, opätovné zostavenie indexov a aktualizácie štatistík. Vyhnite sa prekrývaniu operácií náročných na zdroje, ktoré by mohli spôsobiť zníženie výkonu alebo problémy s časovým limitom. Naplánujte si časové okná údržby na základe prognóz rastu veľkosti databázy a zabezpečte dostatočný čas na úplné overenie integrity s rastúcim objemom údajov.

7.4 Automatizované monitorovanie a upozorňovanie

Konfigurácia SQL Server Upozornenia agentov okamžite upozornia administrátorov, keď DBCC CHECKDB identifikuje poškodenie. Implementujte riešenia analýzy protokolov, ktoré extrahujú a kategorizujú výsledky kontroly integrity, čo umožňuje analýzu trendov a proaktívnu identifikáciu problémov. Vytvorte eskalačné postupy, ktoré definujú časové rámce reakcie a zodpovedných pracovníkov pre rôzne úrovne závažnosti poškodenia.

8. DBCC CHECKTABLE: Ľahká alternatíva

8.1 Kedy použiť CHECKTABLE namiesto CHECKDB

DBCC CHECKTABLE poskytuje cielenú kontrolu integrity jednotlivých tabuliek, vďaka čomu je ideálny pre tarriešenie problémov a údržba špecifických databázových objektov. CHECKTABLE použite pri skúmaní problémov s výkonom konkrétnych tabuliek, overovaní kritických obchodných tabuliek medzi úplnými kontrolami databázy alebo keď časové obmedzenia bránia úplnému overeniu databázy. Tento prístup sa ukazuje ako obzvlášť cenný vo veľkých databázach, kde úplné operácie CHECKDB presahujú dostupné okná údržby.

8.2 Syntax a príklady DBCC CHECKTABLE

Základný príkaz CHECKTABLE tarzískava konkrétne tabuľky:

DBCC CHECKTABLE('YourTable')

Podobne ako CHECKDB, aj CHECKTABLE podporuje rôzne možnosti vrátane NOINDEX pre optimalizáciu výkonu a parametrov opravy pre riešenie poškodenia. Môžete tiež zadať názvy schém pre presnú identifikáciu tabuliek:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Časť tarZameraný prístup umožňuje podrobné overenie integrity a zároveň zachovanie výkonu systému počas pracovnej doby.

8.3 Výhody výkonu pre rozsiahle databázy

Operácie CHECKTABLE sa dokončujú výrazne rýchlejšie ako úplné kontroly databázy, čo umožňuje častejšie overovanie integrity kritických tabuliek. Tento prístup umožňuje denné overovanie základných obchodných tabuliek a zároveň rezervuje komplexné operácie CHECKTABLE pre týždenné alebo mesačné harmonogramy. Znížená spotreba zdrojov robí CHECKTABLE vhodným pre vykonávanie v produkčnom prostredí s minimálnym vplyvom na používateľa.

9. Keď CHECKDB zlyhá

Príkaz DBCC CHECKDB zlyhá v rôznych scenároch vrátane:

• Vykonanie DBCC CHECKDB ukončí sa abnormálne
• Vykonanie príkazu DBCC CHECKDB sa úspešne dokončí, ale možnosti opravy nepodarí sa opraviť databázu.

V týchto scenároch potrebujeme profesionálnejší nástroj, ktorý nám pomôže opraviť chyby v databáze.

9.1 Úvod do DataNumen SQL Recovery

DataNumen SQL Recovery poskytuje pokročilejšie funkcie:

• Najlepšia miera zotavenia v priemysle.
• Obnoviť vážne poškodené súbory databázy.
• Obnoviť všetky databázové objekty vrátane tabuliek, indexov, zobrazení, spúšťačov, pravidiel a predvolených hodnôt.
• Obnovte uložené procedúry, skalárne funkcie, inline funkcie s hodnotou tabuľky a funkcie s hodnotou tabuľky s viacerými príkazmi.
• Obnoviť natrvalo odstránené záznamy.
• Dešifrovať šifrované objekty v SQL Server databáz.
• Dávková oprava súborov MDF.
• Komplexné možnosti opravy.
• Pokročilé protokolovanie a podávanie správ.
• Podpora pre všetkých SQL Server verzia.
• Dostupnosť technickej podpory
• Pravidelné aktualizácie a vylepšenia

9.2 Porovnanie miery úspešnosti

Miera úspešnosti zotavenia sa výrazne líši:

• DBCC CHECKDB a CHECKTABLEC: 1.27% priemerná miera obnovy
• DataNumen: 92.6% rýchlosť zotavenia

Nižšie je uvedené kompletné konkurenčné porovnanie:

9.3 Zotavenie zo závažnej korupcie

Pokročilé funkcie pre ťažké prípady:

• Obnova z fyzicky poškodeného úložiska
• Obnova z naformátovaných diskov alebo havarovaných systémov
• Obnova z diskových obrazov, záložných súborov, diskových súborov virtuálneho počítača, temparary súbory atď.

9.4 Kedy zvážiť profesionálne riešenia

• Žiadna nedávna dostupná záloha
• DBCC CHECKDB zlyhá
• Závažné scenáre korupcie
• Spracovanie kritických obchodných údajov
• Keď je čas kritický
• Keď je nevyhnutné maximálne zotavenie

10. Časté otázky

11. Záver

11.1 Súhrn kľúčových bodov

11.1.1 Zhrnutie základných príkazov DBCC CHECKDB

Zvládnite základnú syntax DBCC CHECKDB pre komplexnú kontrolu databázy, využite možnosti NOINDEX a PHYSICAL_ONLY pre optimalizáciu výkonu a pochopte CHECKTABLE pre taroverenie tabuľky get. Tieto základné príkazy tvoria základ proaktívnej údržby databázy, umožňujú včasné odhalenie poškodenia a systematické monitorovanie integrity.

11.1.2 Pripomienka kľúčových osvedčených postupov

Pred spustením kontrol integrity vždy udržiavajte aktuálne zálohy, naplánujte si pravidelné operácie CHECKDB na základe kritickosti databázy a implementujte automatizované monitorovanie pre okamžité upozornenia na poškodenie. Pamätajte, že prevencia prostredníctvom pravidelného monitorovania prevyšuje reaktívne prístupy a profesionálne riešenia obnovy poskytujú cenné možnosti zálohovania, keď sa štandardné nástroje ukážu ako nedostatočné.

11.2 Kedy použiť DBCC CHECKDB vs. pokročilé riešenia

Na bežné monitorovanie integrity a riešenie menších poškodení používajte nástroj DBCC CHECKDB, pričom profesionálne nástroje na obnovu si vyhraďte pre závažné scenáre poškodenia nad rámec vstavaných možností opravy. Rámec rozhodovania by mal zohľadniť dostupnosť záloh, kritickosť údajov, časové obmedzenia a závažnosť poškodenia. Úspešní správcovia databáz kombinujú pravidelné monitorovanie CHECKDB s komplexnými stratégiami zálohovania a znalosťou pokročilých možností obnovy, keď sa štandardné prístupy ukážu ako nedostatočné.

12. Referencie

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server dokumentáciaSpoločnosť Microsoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „Riešenie problémov s chybami konzistencie databázy hlásenými príkazom DBCC CHECKDB.“ SQL Server dokumentáciaSpoločnosť Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors