DBCC CHECKDB: täielik MS-i juhend SQL Server Andmebaasi tervis (2025)

Andmebaasi korruptsioon on iga SQL Server administraatori õudusunenägu. Kui kriitilised äriandmed muutuvad ligipääsmatuks või ebausaldusväärseks, siis cost võib olla laastav. See põhjalik juhend hõlmab kõike, mida peate teadma DBCC CHECKDB kasutamise kohta andmebaasi tervise säilitamiseks ja korruptsiooni vältimiseks, ning täiustatud taastamislahendusi juhuks, kui standardsetest tööriistadest ei piisa.

1. Tähtsus SQL Server Andmebaasi tervis

1.1 Mis on andmebaasi korruptsioon CostEttevõtted

Täna, most Ettevõtted salvestavad oma kriitilisi andmeid andmebaasidesse. Andmebaasi rikkumise tagajärjed on katastroofilised:

• Rahalised kahjud keskmiselt 2.3 miljonit dollarit aastas andmekao tõttu, mille peamised põhjused on riistvararike ja korruptsioon (EMC Corporation)
• Ettevõtete sulgemise määrad näitavad, et 50% väikeettevõtetest, kellel on riistvararikete tõttu andmete kadu, lõpetavad tegevuse kahe aasta jooksul, samas kui 94% ettevõtetest, kellel on katastroofiline andmete kadu, ei jää üldse ellu
• Andmete rikkumise sagedus mõjutab igal aastal 20% missioonikriitilistest rakendustest, põhjustades äritegevuse järjepidevuse häireid (Gartneri uuring)
• Riistvaraga seotud korruptsioon moodustab 67% kõigist kõvaketta krahhide ja süsteemirikete kaudu toimunud andmekao juhtumitest, kusjuures 40% andmekaost on otseselt seotud riistvaratõrgetega
• Tarkvara korruptsioon costs ulatuvad tuhandetest miljonite dollariteni, olenevalt raskusastmest ja ulatusest, kusjuures 82% ettevõtetest kogesid planeerimata katkestusi, mille peamiseks põhjuseks oli korruptsioon

1.2 Miks on regulaarsed tervisekontrollid kriitilise tähtsusega

Inimesed vajavad regulaarseid tervisekontrolle, et potentsiaalseid haigusi varakult avastada. Samamoodi vajavad regulaarseid tervisekontrolle ka andmebaasid:

1. Avasta potentsiaalne korruptsioon varakult ja tegele sellega viivitamatult, ennetades probleemide süvenemist ja laialdast levikut, mis võib ettevõtte jaoks kaasa tuua katastroofilisi tagajärgi.
2. Veenduge, et andmebaas töötab optimaalse jõudlusega.
3. Cost Ennetavate andmebaasi tervisekontrollide määr on palju madalam kui reaktiivse andmete taastamise määr pärast andmebaasi katastroofi.

1.3 Sissejuhatus andmebaasi terviklikkuse käskudesse

SQL Server pakub mitmeid sisseehitatud käske andmebaasi tervise säilitamiseks, sealhulgas DBCC CHECKDB teenib m-inaost Saadaval on põhjalik terviklikkuse kontrollimise tööriist. Need käsud töötavad koos teie andmebaasi struktuuri erinevate aspektide kontrollimiseks, alates üksikutest tabelitest kuni kogu andmebaasi järjepidevuse kontrollimiseni, moodustades tervikliku hooldusstrateegia, mis hoiab teie andmed turvaliselt ja ligipääsetavana.

2. Mis on DBCC CHECKDB?

DBCC CHECKDB is SQL Serverpeamine tööriist andmebaasi terviklikkuse kontrollimiseks ja korruptsiooniprobleemide tuvastamiseks.

• See on T-SQL-lause, mitte GUI-tööriist.
• Saate seda teha tavaliste meetoditega, näiteks SQL Server Juhtimisstuudio (SSMS), SQL Server Agent, SQLCMD jne.

2.1 Mida CHECKDB teie andmebaasis tegelikult kontrollib

DBCC CHECKDB käivitamisel teostab käsk teie andmebaasi struktuuris mitu valideerimiskihti:

• Lehe kontrollsummade kontrollimine füüsilise korruptsiooni ja riistvaraga seotud probleemide tuvastamiseks
• Indeksi järjepidevuse valideerimine et tagada andmete nõuetekohane hankimine ja päringute toimivus
• Jaotusstruktuuri kontrollid täpse ruumikasutuse ja lehekülgede jaotuse kinnitamiseks
• Viitelise terviklikkuse kontroll seotud tabelite ja võõrvõtme seoste vahel
• Süsteemi tabeli järjepidevuse valideerimine tagamiseks SQL Serversisemised metaandmed jäävad usaldusväärseks
• Andmelehe linkimise kontrollimine leheketi terviklikkuse kinnitamiseks
• Andmebaasi skeemi järjepidevus objektidefinitsioonide ja sõltuvuste valideerimiseks

Need põhjalikud kontrollid hõlmavad nii kasutajaandmeid kui ka süsteemistruktuure, pakkudes täielikku ülevaadet teie andmebaasi seisundist.

3. DBCC CHECKDB käitamine: samm-sammult

3.1 Eeldused

Enne mis tahes DBCC CHECKDB toimingu käivitamist on kontrollnimekiri järgmine:

• Täielik andmebaasi varundamine – Enne terviklikkuse kontrollide tegemist looge täielik varukoopia turvavõrguna juhuks, kui avastatakse andmerike või on vaja parandusi teha.
• Õiged õigused – DBCC CHECKDB käskude täitmiseks on vaja süsteemiadministraatori või andmebaasiomaniku õigusi.
• Piisavad süsteemiressursid:
  • Mälu: 25% andmebaasi suurusest
  • Tempdb ruum: 10–15% andmebaasi suurusest
  • Protsessor: 50–70% saadavus hoolduse ajal
  • I/O: Oodake mahukaid lugemisoperatsioone
• Andmebaasi ligipääsetavus – Veenduge, et teie andmebaas on ligipääsetav ja mitte piiratud olekus, kuna CHECKDB nõuab lugemisõigust kõigile andmebaasi lehtedele.

3.2 Põhikäsk

Most Põhiline DBCC CHECKDB käsk sisaldab kolme levinud varianti:

(1) Kontrollige praegust andmebaasi (parameetriteta):

DBCC CHECKDB

(2) Kontrollige andmebaasi nime järgi:

DBCC CHECKDB ('YourDatabaseName')

(3) Kontrollige andmebaasi ID järgi:

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

See põhikäsk teostab määratud andmebaasi täieliku terviklikkuse kontrolli, uurides kõiki tabeleid, indekseid ja süsteemistruktuure. Andmebaaside puhul, mille standardnimed ei sisalda tühikuid, võite jutumärgid välja jätta. Käsk käivitub kuni lõpuleviimiseni, kuvades edenemisteateid ja lõpptulemusi. See põhisüntaks töötab ideaalselt väiksemate andmebaaside puhul või siis, kui teil on piisavalt hooldusaega.

Allpool on ekraanipilt DBCC CHECKDB käitamisest SQL Server Juhtimisstuudio (SSMS):

3.3 Täielikud valikud

Allpool on toodud DBCC CHECKDB täielikud valikud:

Kategooria	valik	Kirjeldus	DBCC CHECKDB näide
Remondi valikud	REPAIR_REBUILD	Andmete kadumiseta parandused (nt indeksi taastamine)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Remondi pole. Ainult tagasiühilduvus.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Parandab kõik vead (võib põhjustada andmete kadu)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Ulatuse juhtimine	NOINDEX	Jätab vahele klastriteta indeksikontrollid	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Kontrollib ainult füüsilise salvestusruumi terviklikkust (lehed/kirjed)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Kontrollib loogiliste veeruväärtuste vigu (nt sobimatud kuupäevad)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Põhjalikud loogilised kontrollid (indekseeritud vaated, XML/ruumilised indeksid)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Väljundi juhtimine	ALL_ERRORMSGS	Kuvab kõik vead (vaikimisi: 200 objekti kohta)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Peidab informatiivsed sõnumid	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
jõudlus	TABLOCK	Kasutab tabelilukke (vähendab TempDB kasutamist, kuid blokeerib kirjutamise)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Tühistab paralleelsuse sätted	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Kasulikkus	ESTIMATEONLY	Hinnanguline TempDB vajalik ruum. (tegelikku kontrolli ei tehta)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Tulemuste mõistmine

DBCC CHECKDB annab erinevaid tulemusi olenevalt sellest, kas selle täitmine õnnestus või mitte. Selgitame neid üksikasjalikumalt.

4.1 CHECKDB täitmine õnnestus

Kui DBCC CHECKDB käivitamine õnnestub, kuvatakse erinevat tüüpi tulemusi olenevalt teie andmebaasi seisundist.

4.1.1 Probleeme ei leitud

Kui DBCC CHECKDB ei leia probleeme, näete sarnast väljundit:

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

See tulemus näitab, et teie andmebaas säilitab täiusliku terviklikkuse kõigis kontrollitud struktuurides.

4.1.2 Leitud korruptsioonivead

Kui DBCC CHECKDB tuvastab rikkevea, kuvab see järgmise struktuuriga veateate:
Raskusastme juhend:

• Tase 16-19: Kasutaja poolt parandatavad vead, sageli väiksemad rikkumised
• Tase 20-24: Süsteemivead, tõsine korruptsioon, mis nõuab kohest tähelepanu
• 25. tase: Saatuslikud vead, andmebaas võib olla ligipääsmatu

Levinud vead hõlmavad järgmist:

• Lehe kontrollsumma tõrked (sõnum 824)
• Jaotusvead (sõnum 8928)
• Indeksi järjepidevuse probleemid (sõnum 8964)

Sõnumi struktuuri mõistmine aitab prioriseerida reageerimismeetmeid ja määrata kindlaks sobivad taastamisstrateegiad.

4.1.3 Üldised teavitus- ja hoiatusteated

Mitte kõik DBCC CHECKDB väljundid ei viita tõsistele probleemidele. Samuti võivad need kuvada informatiivseid ja hoiatussõnumeid, sealhulgas:

• Remondiavaldused – Sõnumid, mis soovitavad paranduskäsklusi väiksemate probleemide lahendamiseks
• Jaotuse hoiatused – Hoiatused ruumi eraldamise kohta, mis ei mõjuta andmetele juurdepääsu
• Toimivussoovitused – Soovitused indeksi haldamiseks ja optimeerimiseks
• Teavitused – Üldised olekuteated, mis ei vaja kohest tegutsemist

Need teated pakuvad väärtuslikke hooldusjuhiseid, eristades samal ajal kriitilisi rikkeid, mis vajavad kohest tegutsemist, väiksematest probleemidest, mida saab lahendada tavapäraste hooldusperioodide ajal.

Näidishoiatussõnum:

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 CHECKDB täitmise katkestamised

Kui CHECKDB töö katkeb erinevatel põhjustel, annab see veateate ja lisab vealogi alloleva olekukoodiga:

riik	Kirjeldus
0	Tekkis viga number 8930. See viitab metaandmete rikkumisele, mis lõpetas DBCC käsu.
1	Tekkis viga number 8967. Esines sisemine DBCC viga.
2	Avariirežiimi andmebaasi parandamise ajal ilmnes tõrge.
3	See viitab metaandmete rikkumisele, mis lõpetas DBCC käsu.
4	Tuvastati väide või juurdepääsu rikkumine.
5	Tekkis tundmatu viga, mis lõpetas DBCC käsu.

Näidisveateade:

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

Näidis vealogist:

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.

Sellisel juhul võite proovida alternatiivseid täiustatud valikuid, näiteks DataNumen SQL Recovery oma andmebaasi korruptsiooni parandamiseks.

5. Korruptsioonivigade parandamine

5.1 Varundamine ja taastamine: kõige turvalisem lahendus

Kui DBCC CHECKDB tuvastab rikkeid, on puhtast varukoopiast taastamine kõige turvalisem ja tõhusam viis.ost usaldusväärne lahendus. See lähenemisviis tagab andmete terviklikkuse, kõrvaldades samal ajal varundamispõhjused. Enne taastamist kontrollige varukoopia terviklikkust, kasutades TAASTAGE AINULT KINNITUS käske ja kaaluge andmete kadumise minimeerimiseks konkreetseid taastamisvõimalusi. Dokumenteerige rikke üksikasjad algpõhjuse analüüsiks, kuna riistvaraprobleemid või tarkvaravead võivad kordumise vältimiseks vajada täiendavat tähelepanu.

5.2 Lehekülje tasemel korruptsioonilahendused

Üksikute lehevigade korral, mis mõjutavad väikeseid andmeosasid, SQL Server Enterprise Edition pakub lehtede taastamise võimalusi, mis parandavad kahjustatud lehti ilma andmebaasi täieliku taastamiseta. See täiustatud tehnika nõuab täielikku taastamismudelit ja ajakohaseid logide varukoopiaid.

Samm-sammult lehe taastamise protsess:

1. Tuvastage rikutud leht CHECKDB veateate põhjal (nt lk 1:256)
2. Tehke praegusest logist varukoopia hiljutiste tehingute jäädvustamiseks:

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

3. Taasta rikutud leht alates m-istost hiljutine täielik varukoopia:

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

4. Rakenda diferentsiaalvarundust (kui see on olemas):

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

5. Rakenda kõik logide varukoopiad järjest, kaasa arvatud äsja loodud:

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. Tehke viimane logi varukoopia ja taastage see lehe ajakohaseks muutmiseks:

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

Mittekriitiliste andmete alternatiiv: Kui rikutud andmed mõjutavad mittekriitilisi andmeid, võite enne rikutud struktuuride taastamist eksportida puutumata read uutesse tabelitesse:

-- 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 Indeksi rikkumise kiirparandused

Indeksi rikkumine reageerib sageli hästi taastamistoimingutele, mis taastavad indeksistruktuurid ilma aluseks olevaid tabeliandmeid mõjutamata:

ALTER INDEX ALL ON YourTable REBUILD

See lähenemisviis toimib eriti hästi klastriteta indeksi rikkumise korral, kuna taastamine loob indeksilehed uuesti lähteandmete tabelist, kõrvaldades tõhusalt rikkumise ja säilitades samal ajal kogu algse teabe.

6. Kasutage REPAIR_REBUILD ja REPAIR_ALLOW_DATA_LOSS funktsioone

Kui kõik eelnevad meetodid ebaõnnestuvad või pole teostatavad, saate andmebaasi parandamiseks kasutada suvandeid REPAIR_REBUILD ja REPAIR_ALLOW_DATA_LOSS.

6.1 REPAIR_REBUILD (turvalisem variant):

• Kasuta: Indeksi korruptsioon ja väiksemad jaotusvead
• Andmete ohutus: Püüab parandada korruptsiooni ilma andmeid kustutamata
• Riskitase: Madal – andmete kadu ei ole oodata
• Tüüpilised stsenaariumid: Mitteklasterdatud indeksi korruptsioon, väiksemad metaandmete probleemid
• Käsu näide: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Viimane abinõu):

• Kasuta: Tõsine korruptsioon, kui varukoopiad pole saadaval
• Andmete ohutus: Võib andmebaasi funktsionaalsuse taastamiseks rikutud andmed kustutada
• Riskitase: Kõrge – võimalik püsiv andmete kadu
• Tüüpilised stsenaariumid: Lehe korruptsioon, süsteemitabeli kahjustused, jaotusahela vead
• Käsu näide: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Nende valikute parimad tavad:

• Testige alati võimaluse korral andmebaasi koopiate parandamise toimingud
• Varunda alati enne nende valikute käivitamist
• Dokumenteerige kõik muudatused vastavuse ja tõrkeotsingu eesmärgil
• Määra andmebaas ühe kasutaja režiimile enne remonditööde alustamist

Tavaliselt peaksime proovima REMONT_ÜLESEHITAMINE esimene variant. Kui see ebaõnnestub, proovige REPAIR_ALLOW_DATA_LOSS valik.

6.4 REPAIR_ALLOW_DATA_LOSS tulemused

6.4.1 Andmete kadumisega parandus õnnestub

Mõnikord REPAIR_ALLOW_DATA_LOSS valik õnnestub, aga mõned andmed on puudulikud.ost pärast remonti.

Allpool on mõned näidissõnumid:

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.

Seda seetõttu, et DBCC CHECKDB parandab andmebaasi, hüljates mõned kahjustatud kirjed, aga tegelikult most neist saab endiselt taastada DataNumen SQL Recovery.

Näidisfailid:

SQL Server versioon	Rikutud MDF-fail	MDF-fail on parandatud DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Sõnum 8909, millele järgneb sõnum 8939) (600 kirjet lost koos REPAIR_ALLOW_DATA_LOSS-iga)	Viga10_1_fixed.mdf (Kirjestust pole lost)
SQL Server 2014	Error10_2.mdf (Sõnum 8909, millele järgneb sõnum 8939) (6000 kirjet (50%) lost koos REPAIR_ALLOW_DATA_LOSS-iga)	Viga10_2_fixed.mdf (Ainult 100 kirjet lost)
SQL Server 2014	Viga7MDF (100 kirjet lost koos REPAIR_ALLOW_DATA_LOSS-iga)	Error7_fixed.mdf (Ainult üks kirje lost)

6.4.2 Remont ebaõnnestub – kaaluge professionaalset lahendust

If REPAIR_ALLOW_DATA_LOSS ebaõnnestub, väljastab see ühe või mitu veateadet.

Allpool on mõned näited:

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.

Sellistel juhtudel on vaja kasutada professionaalset lahendust, näiteks DataNumen SQL Recovery oma andmebaasi korda tegemiseks.

Näidisfailid

SQL Server versioon	Rikutud MDF-fail	MDF-fail on parandatud DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (Üksiksõnum 824)	Viga1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (Pideva sõnumi 824 vead)	Viga1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((Sõnum 824, millele järgneb sõnum 7909)	Viga1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (Sõnum 8992, millele järgneb sõnum 3852)	Viga4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (Sõnum 8992, millele järgneb sõnum 3852)	Viga4_2_fixed.mdf
SQL Server 2014	Error5.mdf (Sõnum 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (Sõnum 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (Sõnum 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (Sõnum 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (Sõnum 5028)	Error3_fixed.mdf
SQL Server 2014	Viga8MDF (Sõnum 5125)	Viga8_fixed.mdf
SQL Server 2014	Error9.mdf (Sõnum 3313)	Error9_fixed.mdf

7. Parimad tavad

7.1 Regulaarsete CHECKDB toimingute ajastamine

Rakenda kriitiliste tootmisandmebaaside jaoks iganädalast DBCC CHECKDB käivitamist koos igapäevaste kontrollidega suure tehingute arvuga süsteemides. Ajasta toimingud vähese kasutusega perioodidele, et minimeerida jõudlusele avalduvat mõju, ja kaalu täielike kontrollide ja PHYSICAL_ONLY valikute vaheldumist vastavalt andmebaasi suurusele ja hooldusakendele. Automatiseeritud ajastamine läbi SQL Server Agent tagab järjepideva täitmise, pakkudes samal ajal tsentraliseeritud jälgimis- ja teavitusvõimalusi.

7.2 Tulemuslikkuse mõju juhtimine

DBCC CHECKDB toimingud tarbivad märkimisväärsel hulgal süsteemiressursse, mis võib mõjutada samaaegsete kasutajate tegevust. Jälgige kontrollide ajal protsessori kasutust, mälukasutust ja ketta sisend-/väljundtegevust, et mõista jõudluse mõju mustreid. Kaaluge NOINDEX-i valikute kasutamist rutiinsete kontrollide jaoks, reserveerides täieliku valideerimise igakuisteks hooldusakendeks. Rakendage päringu ajalõpu laiendusi ja kasutajatega suhtlemise strateegiaid, et hallata ootusi terviklikkuse kontrollimise perioodide ajal.

7.3 Hooldusakna planeerimine

Koordineerige DBCC CHECKDB ajastamist muude hooldustegevustega, nagu varundustoimingud, indeksi taastamine ja statistika uuendamine. Vältige ressursimahukate toimingute kattumist, mis võib põhjustada jõudluse halvenemist või ajalõpuprobleeme. Planeerige hooldusaknaid andmebaasi suuruse kasvuprognooside põhjal, tagades piisavalt aega terviklikkuse kontrollimiseks andmemahtude suurenedes.

7.4 Automatiseeritud jälgimine ja teavitamine

Seadistamine SQL Server Agent annab administraatoritele koheselt märku, kui DBCC CHECKDB tuvastab rikkumise. Rakendab logide parsimise lahendusi, mis ekstraheerivad ja kategoriseerivad terviklikkuse kontrolli tulemusi, võimaldades trendide analüüsi ja ennetavat probleemide tuvastamist. Loob eskalatsiooniprotseduurid, mis määravad reageerimise ajaraamid ja vastutavad isikud erineva rikkumise raskusastme jaoks.

8. DBCC CHECKTABLE: kerge alternatiiv

8.1 Millal kasutada CHECKTABLE'i CHECKDB asemel

DBCC CHECKTABLE pakub üksikute tabelite sihipärast terviklikkuse kontrolli, mistõttu sobib see ideaalselt tarKonkreetsete andmebaasiobjektide tõrkeotsing ja hooldus. Kasutage CHECKTABLE'i konkreetsete tabelite jõudlusprobleemide uurimiseks, kriitiliste äritabelite valideerimiseks täielike andmebaasikontrollide vahel või kui ajapiirangud takistavad andmebaasi täielikku valideerimist. See lähenemisviis osutub eriti väärtuslikuks suurtes andmebaasides, kus täielikud CHECKDB toimingud ületavad saadaolevaid hooldusaknaid.

8.2 DBCC CHECKTABLE süntaks ja näited

Põhiline CHECKTABLE käsk tarsaab konkreetsed tabelid:

DBCC CHECKTABLE('YourTable')

Nagu CHECKDB, toetab ka CHECKTABLE mitmesuguseid valikuid, sealhulgas NOINDEX jõudluse optimeerimiseks ja parandusparameetreid vigade lahendamiseks. Samuti saate määrata skeeminimed tabeli täpseks tuvastamiseks:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

see tarGeted-lähenemisviis võimaldab detailset terviklikkuse kontrollimist, säilitades samal ajal süsteemi jõudluse tööajal.

8.3 Suurte andmebaaside jõudluse eelised

CHECKTABLE'i toimingud tehakse oluliselt kiiremini kui täielikud andmebaasikontrollid, mis võimaldab kriitiliste tabelite sagedasemat terviklikkuse kontrollimist. See lähenemisviis võimaldab oluliste äritabelite igapäevast valideerimist, reserveerides samal ajal põhjalikud CHECKDB toimingud iganädalasteks või igakuiseks ajakavaks. Väiksem ressursitarbimine muudab CHECKTABLE'i sobivaks tootmiskeskkonnas käivitamiseks minimaalse kasutajamõjuga.

9. Kui CHECKDB ebaõnnestub

DBCC CHECKDB ebaõnnestub mitmel juhul, sealhulgas:

• DBCC CHECKDB täitmine lõpeb ebanormaalselt
• DBCC CHECKDB täitmine lõpeb edukalt, aga remondivõimalused andmebaasi parandamine ebaõnnestub.

Sellistel juhtudel vajame professionaalsemat tööriista, mis aitaks meil andmebaasi vigu parandada.

9.1 Sissejuhatus DataNumen SQL Recovery

DataNumen SQL Recovery pakub täiustatud võimalusi:

• Parim taastumismäär tööstuses.
• Taasta tõsiselt rikutud andmebaasifailid.
• Taastage kõik andmebaasiobjektid, sh tabelid, indeksid, vaated, päästikud, reeglid ja vaikesätted.
• Taastage salvestatud protseduurid, skalaarfunktsioonid, tekstisisesed tabeliväärtusega funktsioonid ja mitmelauseliste tabeliväärtustega funktsioonid.
• Taasta jäädavalt kustutatud kirjed.
• Krüpteeritud objektide dekrüpteerimine SQL Server andmebaasid.
• Paranda MDF-faile partiidena.
• Põhjalikud remondivõimalused.
• Täiustatud logimine ja aruandlus.
• Toetus kõigile SQL Server versioonid.
• Tehnilise toe kättesaadavus
• Regulaarsed värskendused ja täiustused

9.2 Edukuse määra võrdlus

Taastumise edukuse määrad erinevad oluliselt:

• DBCC CHECKDB ja CHECKTABLE: 1.27% keskmine taastumismäär
• DataNumen: 92.6% taastumismäär

Allpool on täielik konkurentsivõimeline võrdlus:

9.3 Toibumine raskest korruptsioonist

Täiustatud võimalused raskete juhtumite jaoks:

• Taastamine füüsiliselt kahjustatud laost
• Taastamine vormindatud draividest või kokkujooksnud süsteemidest
• Taastamine kettapiltidest, varukoopiafailidest, virtuaalmasina kettafailidest, tempostrary failid jne.

9.4 Millal kaaluda professionaalseid lahendusi

• Hiljutist varukoopiat pole saadaval
• DBCC CHECKDB ebaõnnestub
• Tõsised korruptsioonistsenaariumid
• Kriitiliste äriandmetega tegelemine
• Kui aeg on kriitiline
• Kui maksimaalne taastumine on hädavajalik

10. KKK

11. järeldus

11.1 Põhipunktide kokkuvõte

11.1.1 Oluliste DBCC CHECKDB käskude kokkuvõte

Omandage DBCC CHECKDB põhisüntaks andmebaasi põhjalikuks kontrollimiseks, kasutage jõudluse optimeerimiseks NOINDEX ja PHYSICAL_ONLY valikuid ning mõistke CHECKTABLE funktsiooni. targetted tabeli kontrollimine. Need põhikäsklused moodustavad ennetava andmebaasi hoolduse aluse, võimaldades varajast korruptsiooni avastamist ja süstemaatilist terviklikkuse jälgimist.

11.1.2 Oluliste parimate tavade meeldetuletus

Enne terviklikkuse kontrollide käivitamist hoidke alati ajakohaseid varukoopiaid, planeerige regulaarseid CHECKDB toiminguid andmebaasi kriitilisuse põhjal ja rakendage automaatset jälgimist koheste korruptsioonihoiatuste saamiseks. Pidage meeles, et regulaarse jälgimise abil ennetamine ületab reaktiivsed lähenemisviisid ja professionaalsed taastamislahendused pakuvad väärtuslikke varundusvõimalusi, kui standardsed tööriistad osutuvad ebapiisavaks.

11.2 Millal kasutada DBCC CHECKDB-d vs. täiustatud lahendusi

Kasutage DBCC CHECKDB-d rutiinseks terviklikkuse jälgimiseks ja väiksemate vigade lahendamiseks, reserveerides samal ajal professionaalsed taastamistööriistad tõsiste vigade korral, mis ületavad sisseehitatud parandusvõimalusi. Otsustusraamistik peaks arvestama varukoopiate kättesaadavust, andmete kriitilisust, ajapiiranguid ja rikke raskusastet. Edukad andmebaasi administraatorid ühendavad regulaarse CHECKDB jälgimise põhjalike varundusstrateegiate ja teadlikkusega täiustatud taastamisvõimalustest, kui standardsed lähenemisviisid osutuvad ebapiisavateks.

12. Viited

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server dokumentatsioonMicrosoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „DBCC CHECKDB teatatud andmebaasi järjepidevuse vigade tõrkeotsing.“ SQL Server dokumentatsioonMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors