Sisukord peida

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):

Ekraanipilt DBCC CHECKDB käitamisest SQL Server Management Studio (SSMS), sh väljundtulemused.

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:
DBCC CHECKDB veateate struktuuri üksikasjalik selgitus, sh iga osa tähendus.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'
  1. Taasta rikutud leht alates m-istost hiljutine täielik varukoopia:
RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'
  1. Rakenda diferentsiaalvarundust (kui see on olemas):
RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'
  1. 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'
  1. 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:

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:

Taastumismäärade võrdlustabel erinevate riikide vahel. DataNumen SQL Recovery ja teised konkurendid, sealhulgas DBCC CHECKDB ja CHECKTABLE.

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

10.1 Põhilised kasutusküsimused

K: Kui tihti peaksin DBCC CHECKDB-d käivitama?

A: Kriitiliste tootmisandmebaaside puhul käivitage CHECKDB iganädalaselt. Suure tehingute arvuga süsteemide puhul kaaluge igapäevaste kontrollide tegemist, kasutades valikut PHYSICAL_ONLY, ja täielike kontrollide tegemist iganädalaselt. Arendusandmebaase saab kontrollida igakuiselt.

K: Kas ma saan DBCC CHECKDB-d käitada reaalajas tootmisandmebaasis?

A: Jah, DBCC CHECKDB saab töötada võrguandmebaasides kasutajaid blokeerimata. See aga tarbib märkimisväärselt ressursse, seega tuleks see planeerida vähese aktiivsusega perioodidele ja jälgida süsteemi jõudlust.

K: Mis vahe on CHECKDB-l ja CHECKTABLE-l?

A: CHECKDB uurib kogu andmebaasi, samas kui CHECKTABLE keskendub üksikutele tabelitele. Kasutage CHECKTABLE'i selleks, et tartõrkeotsinguks või kui teil on vaja kontrollida konkreetseid tabeleid ilma kogu andmebaasi skannimata.

10.2 Jõudluse ja ressursside küsimused

K: Miks võtab DBCC CHECKDB minu suure andmebaasiga nii kaua aega?

A: CHECKDB kestus sõltub andmebaasi suurusest, riistvara jõudlusest ja kasutatavatest valikutest. Kiiremate kontrollide jaoks kasutage PHYSICAL_ONLY või klastriteta indeksite vahelejätmiseks NOINDEX. Kaaluge käitamist hooldusakende ajal eraldatud ressurssidega.

K: Kui palju ajutist andmebaasiruumi CHECKDB vajab?

A: Üldiselt eraldage CHECKDB toimingute ajal tempdb jaoks 10–15% oma andmebaasi mahust. Täpsete hinnangute saamiseks kasutage valikut ESTIMATEONLY: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

K: Kas ma saan töötava CHECKDB toimingu tühistada?

A: Jah, saate CHECKDB tühistada seansi ID-l käsuga KILL. Tühistamine ei anna aga mingit teavet andmebaasi terviklikkuse kohta ja peate selle hiljem uuesti käivitama.

10.3 Veakäsitlusega seotud küsimused

K: CHECKDB leidis vigu – kas peaksin paanitsema?

A: Ära paanitse, vaid tegutse kiiresti. Esmalt tee kindlaks, kas CHECKDB käivitus edukalt, kuid leidis vigu või kas CHECKDB ise ebaõnnestus. Kontrolli, kas vead mõjutavad ainult klastriteta indekseid (vähem kriitilised) või tabeliandmeid (tõsisemad).

K: Millal peaksin kasutama REPAIR_ALLOW_DATA_LOSS-i?

A: Ainult absoluutselt viimase abinõuna, kui teil pole kasutatavaid varukoopiaid ja andmete kadu on vastuvõetav võrreldes andmebaasi täieliku kadumisega. Proovige alati kõigepealt varukoopiast taastada, kuna parandustoimingud võivad põhjustada jäädava andmekao.

K: Mida tähendavad „andmebaasis esinevad järjepidevuse vead” ja „jaotuse vead”?

A: Jaotusvead mõjutavad seda, kuidas SQL Server jälgib kettaruumi kasutamist, samas kui järjepidevuse vead viitavad andmete või indeksistruktuuride probleemidele. Mõlemad vajavad tähelepanu, kuid järjepidevuse vead mõjutavad andmete kättesaadavust tavaliselt otsesemalt.

10.4 Varundamise ja taastamise küsimused

K: Kas peaksin oma varukoopiate puhul CHECKDB-d käivitama?

A: Absoluutselt! Käivita CHECKDB pärast varukoopiate taastamist testserveritesse. See kontrollib varukoopiate terviklikkust ja tagab, et sa saad riknemisest taastuda. Automatiseeri see protsess võimaluse korral.

K: Ka minu varukoopia on rikutud – mis nüüd saab?

A: Proovige vanemaid varukoopiaid, kuni leiate puhta varukoopia. Kui puhtaid varukoopiaid pole, kaaluge professionaalseid taastamislahendusi, näiteks DataNumen SQL RecoveryDokumenteerige korruptsiooni ajajoon, et vältida tulevasi kordumisi.

K: Kas lehe taastamine saab parandada riknemist ilma andmebaasi täieliku taastamiseta?

A: Jah, aga ainult SQL Server Ettevõtte versioon täieliku taastamismudeli ja ajakohaste logide varukoopiatega. Lehe taastamine toimib üksikute lehtede rikutud kohtade korral, kuid nõuab hoolikat teostamist õigete protseduuride järgimise järgi.

10.5 Veaotsingu küsimused

K: CHECKDB annab tõrkeid „ruumist puudu“ – mida ma saan teha?

A: Vabastage tempdb ruumi, teisaldage tempdb kiiremale salvestusruumile või kasutage tempdb kasutuse vähendamiseks valikut TABLOCK. Ressursinõuete vähendamiseks kaaluge CHECKDB käitamist koos NOINDEXi või PHYSICAL_ONLY-ga.

K: Kuidas ma saan CHECKDB väljundist tuvastada, millises tabelis on andmed rikutud?

A: Otsi veateadetest „objekti ID” numbreid ja seejärel kasuta: SELECT OBJECT_NAME(object_id) tabeli nimede leidmiseks. Veateated sisaldavad ka lehekülje ja pesa numbreid täpseks asukoha tuvastamiseks.

K: Kas riistvaraprobleemid võivad põhjustada CHECKDB valepositiivsete tulemuste kuvamist?

A: Jah, riistvara (eriti salvestusruumi) rike võib põhjustada vahelduvat viga, mis ilmub ja kaob CHECKDB käitamise vahel. Kui vead on vastuolulised, uurige oma I/O-alamsüsteemi ja käivitage mitu kontrolli mustrite kinnitamiseks.

10.6 Täpsemad konfiguratsiooniküsimused

K: Millised jälgimislipud saavad CHECKDB jõudlust parandada?

A: Jälgimislipp 2562 saab parandada jõudlust, käivitades CHECKDB ühe partiina. Jälgimislipp 2549 on abiks, kui andmebaasifailid asuvad eraldi ketastel. Kasutage neid hoolikalt ja testige esmalt mittetootmiskeskkonnas.

K: Kuidas automatiseerida CHECKDB jälgimist ja teavitamist?

A: Kasutama SQL Server Agent saadab teateid veanumbrite 8930, 8939 ja muude kohta. Rakenda logide parsimist CHECKDB tulemuste ekstraheerimiseks ja loo teavitusi vigade avastamise kohta. Kaalu hoolduslahenduste raamistike, näiteks Ola Hallengreni skriptide, kasutamist.

K: Kas peaksin kasutama valikut EXTENDED_LOGICAL_CHECKS?

A: Ainult siis, kui kahtlustate keerulist loogikaristust ja teil on piisav jõudluskoormus. See valik teeb täiendavaid kontrolle indekseeritud vaadete, XML-indeksite ja ruumiliste indeksite osas, kuid suurendab oluliselt täitmisaega.

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