DBCC CHECKDB: Popoln vodnik po MS SQL Server Zdravje podatkovne baze (2025)

Poškodba baze podatkov je vsaka SQL Server Nočna mora skrbnika. Ko ključni poslovni podatki postanejo nedostopni ali nezanesljivi, cost je lahko uničujoče. Ta obsežen vodnik zajema vse, kar morate vedeti o uporabi DBCC CHECKDB za vzdrževanje zdravja baze podatkov in preprečevanje poškodb, ter napredne rešitve za obnovitev, kadar standardna orodja niso dovolj.

1. Pomen SQL Server Zdravje baze podatkov

1.1 Kaj povzroča poškodbe podatkovne baze CostPodjetja

Danes, most Podjetja shranjujejo svoje kritične podatke v podatkovnih bazah. Posledice poškodb podatkovnih baz so katastrofalne:

• Finančne izgube povprečno 2.3 milijona dolarjev letno zaradi izgube podatkov, pri čemer sta glavna vzroka okvara strojne opreme in poškodba (EMC Corporation)
• Stopnje zaprtja podjetij kažejo, da 50 % malih podjetij, ki zaradi okvar strojne opreme izgubijo podatke, propade v dveh letih, medtem ko 94 % podjetij s katastrofalno izgubo podatkov sploh ne preživi.
• Pogostost poškodb podatkov vsako leto prizadene 20 % kritičnih aplikacij in povzroča motnje v neprekinjenem poslovanju (raziskava Gartnerja)
• Poškodbe, povezane s strojno opremo predstavlja 67 % vseh primerov izgube podatkov zaradi okvar trdega diska in sistemskih napak, pri čemer je 40 % izgube podatkov neposredno posledica okvar strojne opreme.
• Poškodba programske opreme costs segajo od tisoč do milijonov dolarjev, odvisno od resnosti in obsega, pri čemer je 82 % podjetij doživelo nenačrtovane izpade, pri katerih je bila korupcija glavni vzrok

1.2 Zakaj so redni zdravstveni pregledi ključnega pomena

Ljudje potrebujejo redne zdravstvene preglede za zgodnje odkrivanje morebitnih bolezni. Podobno tudi baze podatkov potrebujejo redne zdravstvene preglede:

1. Zgodaj odkrijte morebitno korupcijo in jo pravočasno obravnavajte, da preprečite, da bi težave postale resne in razširjene, kar bi lahko povzročilo katastrofalne posledice za podjetje.
2. Zagotovite, da baza podatkov deluje optimalno.
3. Cost Proaktivni pregledi zdravja baze podatkov so veliko nižji od reaktivnega obnavljanja podatkov po katastrofi baze podatkov.

1.3 Uvod v ukaze za integriteto baze podatkov

SQL Server ponuja več vgrajenih ukazov za vzdrževanje zdravja baze podatkov, z DBCC CHECKDB služi kot most Na voljo je celovito orodje za preverjanje integritete. Ti ukazi skupaj preverjajo različne vidike strukture vaše baze podatkov, od posameznih tabel do skladnosti celotne baze podatkov, in tvorijo celovito strategijo vzdrževanja, ki zagotavlja varnost in dostopnost vaših podatkov.

2. Kaj je DBCC CHECKDB

DBCC CHECKDB is SQL Serverje glavno orodje za preverjanje integritete baze podatkov in odkrivanje težav s korupcijo.

• To je stavek T-SQL, ne orodje z grafičnim uporabniškim vmesnikom.
• Izvedete ga lahko z običajnimi metodami, kot so SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD itd.

2.1 Kaj CHECKDB dejansko preveri v vaši bazi podatkov

Ko zaženete ukaz DBCC CHECKDB, ukaz izvede več plasti preverjanja v strukturi baze podatkov:

• Preverjanje kontrolnih vsot strani za odkrivanje fizičnih poškodb in težav, povezanih s strojno opremo
• Preverjanje skladnosti indeksa za zagotovitev pravilnega pridobivanja podatkov in delovanja poizvedb
• Preverjanja strukture dodeljevanja za potrditev natančne uporabe prostora in dodelitve strani
• Preizkus referenčne integritete med povezanimi tabelami in odnosi s tujim ključem
• Preverjanje skladnosti sistemske tabele da se zagotovi SQL ServerNotranji metapodatki ostajajo zanesljivi
• Preverjanje povezave podatkovnih strani za potrditev pravilne integritete verige strani
• Skladnost sheme baze podatkov za preverjanje definicij in odvisnosti objektov

Ti celoviti pregledi zajemajo tako uporabniške podatke kot sistemske strukture, kar zagotavlja popoln vpogled v stanje vaše baze podatkov.

3. Izvajanje ukaza DBCC CHECKDB: korak za korakom

Predpogoji za 3.1

Spodaj je kontrolni seznam pred izvedbo katere koli operacije DBCC CHECKDB:

• Popolna varnostna kopija baze podatkov – Preden izvedete preverjanje integritete, ustvarite popolno varnostno kopijo, ki bo vaša varnostna mreža v primeru odkritja poškodb ali potrebe po popravilih.
• Ustrezna dovoljenja – Za izvajanje ukazov DBCC CHECKDB potrebujete dovoljenja sysadmin ali db_owner.
• Zadostni sistemski viri:
  • Pomnilnik: 25 % velikosti baze podatkov
  • Prostor za začasno bazo podatkov: 10–15 % velikosti baze podatkov
  • CPU: 50–70 % razpoložljivost med vzdrževanjem
  • V/I: Pričakujte obsežne bralne operacije
• Dostopnost baze podatkov – Preverite, ali je vaša baza podatkov dostopna in ni v omejenem stanju, saj CHECKDB zahteva bralni dostop do vseh strani baze podatkov.

3.2 Osnovni ukaz

Most Osnovni ukaz DBCC CHECKDB vključuje tri pogoste različice:

(1) Preverite trenutno bazo podatkov (brez parametrov):

DBCC CHECKDB

(2) Preverite bazo podatkov po imenu:

DBCC CHECKDB ('YourDatabaseName')

(3) Preveri bazo podatkov po ID-ju:

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

Ta osnovni ukaz izvede popolno preverjanje integritete določene baze podatkov, pri čemer pregleda vse tabele, indekse in sistemske strukture. Pri bazah podatkov s standardnimi imeni, ki ne vsebujejo presledkov, lahko narekovaje izpustite. Ukaz se bo izvajal do zaključka in prikazoval sporočila o napredku ter končne rezultate. Ta osnovna sintaksa deluje odlično za manjše baze podatkov ali kadar imate na voljo dovolj časa za vzdrževanje.

Spodaj je posnetek zaslona z izvajanjem DBCC CHECKDB v SQL Server Management Studio (SSMS):

3.3 Popolne možnosti

Spodaj so navedene vse možnosti za DBCC CHECKDB:

Kategorija	Možnost	Opis	Primer DBCC CHECKDB
Možnosti popravila	REPAIR_REBUILD	Popravila brez izgube podatkov (npr. obnova indeksov)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Brez popravila. Samo združljivost s prejšnjimi različicami.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Popravi vse napake (lahko povzroči izgubo podatkov)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Nadzor obsega	NOINDEX	Preskoči preverjanja neklasteriranih indeksov	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Preveri samo celovitost fizičnega pomnilnika (strani/zapisi)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Preveri logične napake v vrednostih stolpcev (npr. neveljavne datume)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Globoka logična preverjanja (indeksirani pogledi, XML/prostorski indeksi)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Izhodni nadzor	ALL_ERRORMSGS	Prikaže vse napake (privzeto: 200 na objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Skrije informativna sporočila	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Uspešnost	TABLOCK	Uporablja zaklepanje tabel (zmanjša uporabo TempDB, vendar blokira pisanje)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Preglasi nastavitve vzporednosti	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Utility	ESTIMATEONLY	Oceni potreben prostor v začasni zbirki podatkov (brez dejanskega preverjanja).	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Razumevanje vaših rezultatov

DBCC CHECKDB bo dal različne rezultate glede na to, ali se je njegovo izvajanje uspešno zaključilo ali ne. Oglejmo si jih podrobneje.

4.1 Izvajanje ukaza CHECKDB se je uspešno zaključilo

Če se izvajanje ukaza DBCC CHECKDB uspešno zaključi, bo sporočil različne vrste rezultatov, odvisno od stanja baze podatkov.

4.1.1 Ni najdenih težav

Če DBCC CHECKDB ne najde nobenih težav, se bo prikazal izpis, podoben temu:

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

Ta rezultat kaže, da vaša baza podatkov ohranja popolno integriteto v vseh preverjenih strukturah.

4.1.2 Najdene napake zaradi korupcije

Kadar koli DBCC CHECKDB zazna napako zaradi korupcije, bo sporočil sporočilo o napaki z naslednjo strukturo:
Vodnik po stopnjah resnosti:

• Raven 16-19: Napake, ki jih lahko uporabnik popravi, pogosto manjše poškodbe
• Raven 20-24: Sistemske napake, resna korupcija, ki zahteva takojšnjo pozornost
• Raven 25: Usodne napake, baza podatkov morda ni dostopna

Pogoste napake vključujejo:

• Napake kontrolne vsote strani (sporočilo 824)
• Napake pri dodelitvi (sporočilo 8928)
• Težave z doslednostjo indeksa (sporočilo 8964)

Razumevanje strukture sporočila pomaga pri določanju prioritet odzivnih ukrepov in ustreznih strategij za obnovitev.

4.1.3 Pogosta informativna in opozorilna sporočila

Vsi izpisi ukaza DBCC CHECKDB ne kažejo na resne težave. Izpiše lahko tudi nekaj informativnih in opozorilnih sporočil, vključno z:

• Izjave o popravilu – Sporočila, ki predlagajo ukaze za odpravljanje manjših težav
• Opozorila o dodelitvi – Opozorila o dodelitvi prostora, ki ne vplivajo na dostop do podatkov
• Priporočila za učinkovitost delovanja – Predlogi za vzdrževanje in optimizacijo indeksa
• Informativna obvestila – Splošna sporočila o stanju, ki ne zahtevajo takojšnjega ukrepanja

Ta sporočila zagotavljajo dragocene smernice za vzdrževanje, hkrati pa razlikujejo med kritičnimi poškodbami, ki zahtevajo takojšnje ukrepanje, in manjšimi težavami, ki jih je mogoče odpraviti med rednim vzdrževanjem.

Primer opozorilnega sporočila:

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 Prekinitve izvajanja CHECKDB

Če se CHECKDB med izvajanjem prekine zaradi različnih razlogov, bo sporočil sporočilo o napaki in dodal dnevnik napak s spodnjo kodo stanja:

Država	Opis
0	Pojavila se je napaka številka 8930. To kaže na poškodbo metapodatkov, ki je prekinila ukaz DBCC.
1	Sprožena je bila napaka številka 8967. Prišlo je do notranje napake DBCC.
2	Med popravilom baze podatkov v nujnem načinu je prišlo do napake.
3	To kaže na poškodbo metapodatkov, ki je prekinila ukaz DBCC.
4	Zaznana je bila kršitev trditve ali dostopa.
5	Prišlo je do neznane napake, ki je prekinila ukaz DBCC.

Primer sporočila o napaki:

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

Primer dnevnika napak:

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 takem primeru lahko poskusite z alternativnimi naprednimi možnostmi, kot so DataNumen SQL Recovery da odpravite poškodbe v vaši bazi podatkov.

5. Odpravljanje napak zaradi korupcije

5.1 Varnostno kopiranje in obnovitev: Najvarnejša rešitev

Ko DBCC CHECKDB zazna napake pri poškodbah, je obnovitev iz čiste varnostne kopije najvarnejša in najučinkovitejša.ost zanesljiva rešitev. Ta pristop zagotavlja celovitost podatkov, hkrati pa odpravlja osnovne vzroke za poškodbe. Pred obnovitvijo preverite celovitost varnostne kopije z uporabo OBNOVITEV SAMO POTRJENO ukaze in razmislite o možnostih obnovitve v določenem trenutku, da zmanjšate izgubo podatkov. Dokumentirajte podrobnosti o poškodbah za analizo vzroka, saj lahko težave s strojno opremo ali programske napake zahtevajo dodatno pozornost, da se prepreči ponovitev.

5.2 Rešitve za korupcijo na ravni strani

Za izolirane poškodbe strani, ki vplivajo na majhne dele podatkov, SQL Server Izdaja Enterprise ponuja zmožnosti obnovitve strani, ki popravijo določene poškodovane strani brez popolne obnove baze podatkov. Ta napredna tehnika zahteva model popolne obnovitve in trenutne varnostne kopije dnevnikov.

Postopek obnovitve strani po korakih:

1. Prepoznajte poškodovano stran iz sporočila o napaki CHECKDB (npr. stran 1:256)
2. Naredite varnostno kopijo trenutnega dnevnika za zajem nedavnih transakcij:

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

3. Obnovi poškodovano stran od most nedavna popolna varnostna kopija:

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

4. Uporabi diferencialno varnostno kopijo (če je na voljo):

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

5. Uporabi vse varnostne kopije dnevnikov v zaporedju, vključno s pravkar ustvarjenim:

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. Naredite končno varnostno kopijo dnevnika in jo obnovite za posodobitev strani:

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

Alternativa za nekritične podatke: Če poškodba vpliva na nekritične podatke, lahko izvozite nespremenjene vrstice v nove tabele, preden obnovite poškodovane strukture:

-- 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 Hitre rešitve za poškodbe indeksa

Poškodba indeksa se pogosto dobro odzove na operacije ponovne izgradnje, ki ponovno izdelajo strukture indeksov, ne da bi to vplivalo na podatke v osnovni tabeli:

ALTER INDEX ALL ON YourTable REBUILD

Ta pristop deluje še posebej dobro pri poškodbah neklasteriranih indeksov, saj ponovna izgradnja regenerira strani indeksa iz podatkov izvorne tabele, s čimer učinkovito odpravi poškodbe, hkrati pa ohrani vse izvirne informacije.

6. Uporabite REPAIR_REBUILD in REPAIR_ALLOW_DATA_LOSS

Če prejšnje metode ne uspejo ali niso izvedljive, lahko za popravilo baze podatkov uporabite možnosti REPAIR_REBUILD in REPAIR_ALLOW_DATA_LOSS.

6.1 POPRAVILO_OBNOVA (Varnejša možnost):

• Uporabi za: Poškodba indeksa in manjše napake pri dodeljevanju
• Varnost podatkov: Poskusi odpravljanja poškodb brez brisanja podatkov
• Stopnja tveganja: Nizka – ni pričakovati izgube podatkov
• Tipični scenariji: Poškodba neklasternega indeksa, manjše težave z metapodatki
• Primer ukaza: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 POPRAVILO_DOVOLJENJE_IZGUBE_PODATKOV (zadnja možnost):

• Uporabi za: Huda poškodba, ko varnostne kopije niso na voljo
• Varnost podatkov: Lahko izbriše poškodovane podatke za obnovitev funkcionalnosti baze podatkov
• Stopnja tveganja: Visoka – možna trajna izguba podatkov
• Tipični scenariji: Poškodba strani, poškodba sistemske tabele, napake v verigi dodeljevanja
• Primer ukaza: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Najboljše prakse za te možnosti:

• Vedno preizkusite popravil kopij baz podatkov, kadar je to mogoče
• Vedno varnostno kopiraj preden zaženete te možnosti
• Dokumentirajte vse spremembe za namene skladnosti in odpravljanja težav
• Nastavitev baze podatkov na enouporabniški način pred začetkom popravil

Običajno bi morali poskusiti POPRAVILO_OBNOVA možnost najprej. Če ne uspe, poskusite REPAIR_ALLOW_DATA_LOSS možnost.

6.4 Rezultati POPRAVILA_DOVOLJENJA_IZGUBE_PODATKOV

6.4.1 Popravilo uspe z izgubo podatkov

Včasih REPAIR_ALLOW_DATA_LOSS možnost bo uspešna, vendar so nekateri podatki izgubljeniost po popravilu.

Spodaj je nekaj vzorčnih sporočil:

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.

To je zato, ker DBCC CHECKDB popravi bazo podatkov tako, da opusti nekatere poškodovane zapise, vendar dejansko most od njih jih je še vedno mogoče obnoviti prek DataNumen SQL Recovery.

Vzorčne datoteke:

SQL Server različica	Poškodovana datoteka MDF	Datoteko MDF je popravil DataNumen SQL Recovery
SQL Server 2014	Napaka10_1.mdf (Sporočilo 8909, ki mu sledi sporočilo 8939) (600 zapisov lost z možnostjo POPRAVILO_DOVOLJENJE_IZGUBE_PODATKOV)	Napaka10_1_fixed.mdf (Ni zapisa lost)
SQL Server 2014	Napaka10_2.mdf (Sporočilo 8909, ki mu sledi sporočilo 8939) (6000 zapisov (50 %) lost z možnostjo POPRAVILO_DOVOLJENJE_IZGUBE_PODATKOV)	Napaka10_2_fixed.mdf (Samo 100 zapisovost)
SQL Server 2014	Napaka7.mdf (100 zapisov lost z možnostjo POPRAVILO_DOVOLJENJE_IZGUBE_PODATKOV)	Napaka7_fixed.mdf (Samo en zapis lost)

6.4.2 Popravilo ne uspe – razmislite o strokovni rešitvi

If REPAIR_ALLOW_DATA_LOSS če ne uspe, bo izpisal eno ali več sporočil o napaki.

Spodaj je nekaj primerov:

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 teh primerih morate uporabiti profesionalno rešitev, kot je npr. DataNumen SQL Recovery da popravite svojo bazo podatkov.

Vzorčne datoteke

SQL Server različica	Poškodovana datoteka MDF	Datoteko MDF je popravil DataNumen SQL Recovery
SQL Server 2014	Napaka1_3.mdf (Eno sporočilo 824)	Napaka1_3_fixed.mdf
SQL Server 2014	Napaka1_1.mdf (Nenehno sporočilo napake 824)	Napaka1_1_popravljeno.mdf
SQL Server 2014	Napaka1_2.mdf ((Sporočilo 824, ki mu sledi sporočilo 7909)	Napaka1_2_fixed.mdf
SQL Server 2014	Napaka4_1.mdf (Sporočilo 8992, ki mu sledi sporočilo 3852)	Napaka4_1_fixed.mdf
SQL Server 2014	Napaka4_2.mdf (Sporočilo 8992, ki mu sledi sporočilo 3852)	Napaka4_2_fixed.mdf
SQL Server 2014	Napaka 5.mdf (Sporočilo 8945)	Napaka5_fixed.mdf
SQL Server 2014	Napaka 6.mdf (Sporočilo 2510)	Napaka6_fixed.mdf
SQL Server 2014	Napaka 2.mdf (Sporočilo 2575)	Napaka2_fixed.mdf
SQL Server 2014	Napaka 11.mdf (Sporočilo 8905)	Napaka11_fixed.mdf
SQL Server 2014	Napaka 3.mdf (Sporočilo 5028)	Napaka3_fixed.mdf
SQL Server 2014	Napaka8.mdf (Sporočilo 5125)	Napaka8_popravljeno.mdf
SQL Server 2014	Napaka 9.mdf (Sporočilo 3313)	Napaka9_fixed.mdf

7. Najboljše prakse

7.1 Načrtovanje rednih operacij CHECKDB

Za kritične produkcijske baze podatkov uvedite tedensko izvajanje ukaza DBCC CHECKDB, za sisteme z veliko transakcijami pa dnevna preverjanja. Načrtujte operacije v obdobjih z nizko uporabo, da zmanjšate vpliv na zmogljivost, in razmislite o preklapljanju med popolnimi preverjanji in možnostmi PHYSICAL_ONLY glede na velikost baze podatkov in vzdrževalna okna. Avtomatizirano načrtovanje prek SQL Server Agent zagotavlja dosledno izvajanje, hkrati pa omogoča centralizirano spremljanje in opozarjanje.

7.2 Upravljanje vpliva na uspešnost

Operacije DBCC CHECKDB porabljajo znatne sistemske vire, kar lahko vpliva na sočasno dejavnost uporabnikov. Med preverjanji spremljajte izkoriščenost procesorja, porabo pomnilnika in vhodno/izhodne operacije diska, da razumete vzorce vpliva na zmogljivost. Za rutinska preverjanja razmislite o uporabi možnosti NOINDEX, celotno preverjanje pa rezervirajte za mesečna vzdrževalna okna. Za upravljanje pričakovanj med obdobji preverjanja integritete implementirajte podaljšanja časovnih omejitev poizvedb in strategije komunikacije z uporabniki.

7.3 Načrtovanje vzdrževalnega obdobja

Uskladite razporejanje DBCC CHECKDB z drugimi vzdrževalnimi dejavnostmi, kot so varnostno kopiranje, obnova indeksov in posodobitve statističnih podatkov. Izogibajte se prekrivanju operacij, ki zahtevajo veliko virov in bi lahko povzročile zmanjšanje zmogljivosti ali težave s časovno omejitvijo. Načrtujte vzdrževalna okna na podlagi projekcij rasti velikosti baze podatkov in zagotovite zadosten čas za popolno preverjanje integritete, ko se količina podatkov povečuje.

7.4 Avtomatizirano spremljanje in opozarjanje

Konfiguracija SQL Server Opozorila agenta, da takoj obvesti skrbnike, ko DBCC CHECKDB zazna poškodbo. Implementirajte rešitve za razčlenjevanje dnevnikov, ki izvlečejo in kategorizirajo rezultate preverjanja integritete, kar omogoča analizo trendov in proaktivno prepoznavanje težav. Ustvarite postopke eskalacije, ki določajo časovne okvire odziva in odgovorno osebje za različne stopnje resnosti poškodb.

8. DBCC CHECKTABLES: Lahka alternativa

8.1 Kdaj uporabiti CHECKTABLE namesto CHECKDB

DBCC CHECKTABLE omogoča osredotočeno preverjanje integritete posameznih tabel, zaradi česar je idealen za tarodpravljanje težav in vzdrževanje določenih objektov baze podatkov. CHECKTABLE uporabite pri preučevanju težav z zmogljivostjo določenih tabel, preverjanju kritičnih poslovnih tabel med popolnimi preverjanji baze podatkov ali kadar časovne omejitve preprečujejo popolno preverjanje baze podatkov. Ta pristop se izkaže za še posebej dragocenega v velikih bazah podatkov, kjer celotne operacije CHECKDB presegajo razpoložljiva okna vzdrževanja.

8.2 Sintaksa in primeri DBCC CHECKTABLE

Osnovni ukaz CHECKTABLE tardobi določene tabele:

DBCC CHECKTABLE('YourTable')

Tako kot CHECKDB tudi CHECKTABLE podpira različne možnosti, vključno z NOINDEX za optimizacijo delovanja in parametri za popravilo poškodb. Za natančno identifikacijo tabel lahko določite tudi imena shem:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Ta tarZagotovljen pristop omogoča podrobno preverjanje integritete, hkrati pa ohranja delovanje sistema med delovnim časom.

8.3 Prednosti delovanja za velike baze podatkov

Operacije CHECKTABLE se zaključijo bistveno hitreje kot popolna preverjanja baze podatkov, kar omogoča pogostejše preverjanje integritete kritičnih tabel. Ta pristop omogoča dnevno preverjanje bistvenih poslovnih tabel, medtem ko celovite operacije CHECKTABLE rezervira za tedenske ali mesečne urnike. Zaradi zmanjšane porabe virov je CHECKTABLE primeren za izvajanje v produkcijskem okolju z minimalnim vplivom na uporabnika.

9. Ko CHECKDB ne uspe

DBCC CHECKDB ne bo uspel v različnih scenarijih, vključno z:

• Izvedba DBCC CHECKDB se nenormalno konča
• Izvajanje ukaza DBCC CHECKDB se uspešno zaključi, vendar možnosti popravila ne uspe popraviti baze podatkov.

V teh primerih potrebujemo bolj profesionalno orodje, ki nam bo pomagalo odpraviti poškodbe v bazi podatkov.

9.1 Uvod v DataNumen SQL Recovery

DataNumen SQL Recovery ponuja naprednejše zmogljivosti:

• Najboljša stopnja okrevanja v industriji.
• Obnovite močno poškodovane datoteke baze podatkov.
• Obnovi vse objekte baze podatkov, vključno s tabelami, indeksi, pogledi, sprožilci, pravili in privzetimi vrednostmi.
• Obnovite shranjene procedure, skalarne funkcije, vgrajene funkcije z vrednostjo tabele in funkcije z vrednostjo tabele z več stavki.
• Obnovite trajno izbrisane zapise.
• Dešifriraj šifrirane predmete v SQL Server podatkovnih baz.
• Popravite datoteke MDF v paketu.
• Celovite možnosti popravila.
• Napredno beleženje in poročanje.
• Podpora vsem SQL Server različice.
• Razpoložljivost tehnične podpore
• Redne posodobitve in izboljšave

9.2 Primerjava stopenj uspešnosti

Stopnje uspešnosti okrevanja se bistveno razlikujejo:

• DBCC CHECKDB in CHECKTABLEC: 1.27% povprečna stopnja okrevanja
• DataNumen: 92.6% stopnja okrevanja

Spodaj je popolna konkurenčna primerjava:

9.3 Okrevanje po hudi korupciji

Napredne zmogljivosti za hude primere:

• Obnovitev po fizično poškodovanem pomnilniku
• Obnovitev po formatiranih pogonih ali zrušenih sistemih
• Obnovitev iz slik diska, datotek varnostne kopije, datotek diska virtualnega stroja, temparary datoteke itd.

9.4 Kdaj razmisliti o profesionalnih rešitvah

• Ni nedavne razpoložljivosti varnostnih kopij
• DBCC CHECKDB ne uspe
• Hudi scenariji korupcije
• Obravnavanje kritičnih poslovnih podatkov
• Ko je čas kritičen
• Ko je nujno maksimalno okrevanje

10. Pogosta vprašanja

11. Zaključek

11.1 Povzetek ključnih točk

11.1.1 Povzetek bistvenih ukazov DBCC CHECKDB

Obvladajte osnovno sintakso DBCC CHECKDB za celovito preverjanje baze podatkov, uporabite možnosti NOINDEX in PHYSICAL_ONLY za optimizacijo delovanja ter razumite CHECKTABLE za tarpreverjanje tabele get. Ti temeljni ukazi tvorijo temelj proaktivnega vzdrževanja baze podatkov, kar omogoča zgodnje odkrivanje poškodb in sistematično spremljanje integritete.

11.1.2 Opomnik o ključnih najboljših praksah

Preden izvedete preverjanje integritete, vedno vzdržujte posodobljene varnostne kopije, načrtujte redne operacije CHECKDB glede na kritičnost baze podatkov in uvedite avtomatizirano spremljanje za takojšnja opozorila o poškodbah. Ne pozabite, da preprečevanje z rednim spremljanjem presega reaktivne pristope, profesionalne rešitve za obnovitev pa ponujajo dragocene možnosti varnostnega kopiranja, ko se standardna orodja izkažejo za nezadostna.

11.2 Kdaj uporabiti DBCC CHECKDB v primerjavi z naprednimi rešitvami

Za rutinsko spremljanje integritete in reševanje manjših poškodb uporabite DBCC CHECKDB, medtem ko za resnejše primere poškodb, ki presegajo vgrajene zmogljivosti popravljanja, uporabite profesionalna orodja za obnovitev. Okvir odločanja mora upoštevati razpoložljivost varnostnih kopij, kritičnost podatkov, časovne omejitve in resnost poškodb. Uspešni skrbniki baz podatkov združujejo redno spremljanje CHECKDB s celovitimi strategijami varnostnega kopiranja in poznavanjem naprednih možnosti obnovitve, ko se standardni pristopi izkažejo za neustrezne.

12. Literatura

1. Microsoft Learn. »DBCC CHECKDB (Transact-SQL).« SQL Server dokumentacijaKorporacija Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. »Odpravljanje napak v skladnosti baze podatkov, ki jih poroča DBCC CHECKDB.« SQL Server dokumentacijaKorporacija Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors