DBCC CHECKDB: Täydellinen opas MS:ään SQL Server Tietokannan terveys (2025)

Tietokannan korruptio on jokaista SQL Server ylläpitäjän painajainen. Kun kriittiset liiketoimintatiedot muuttuvat käyttökelvottomiksi tai epäluotettaviksi, cost voi olla tuhoisaa. Tämä kattava opas kattaa kaiken, mitä sinun tarvitsee tietää DBCC CHECKDB:n käytöstä tietokannan kunnon ylläpitämiseksi ja vioittumisen estämiseksi, sekä edistyneitä palautusratkaisuja tilanteisiin, joissa vakiotyökalut eivät riitä.

1. Tärkeys SQL Server Tietokannan terveys

1.1 Mitä tietokannan korruptio CostYritykset

Tänään, most Yritykset tallentavat kriittiset tietonsa tietokantoihin. Tietokannan vioittumisen seuraukset ovat katastrofaaliset:

• Taloudelliset tappiot keskimäärin 2.3 miljoonaa dollaria vuodessa tietojen menetyksen vuoksi, ja laitteistoviat ja vioittuminen ovat tärkeimmät syyt (EMC Corporation)
• Yritysten lopettamisasteet osoittavat, että 50 % laitteistovikojen vuoksi tietojen menetystä kokevista pienyrityksistä ajautuu konkurssiin kahden vuoden kuluessa, kun taas 94 % yrityksistä, joissa on tapahtunut katastrofaalinen tietojen menetys, ei selviä lainkaan
• Tietojen korruptoitumisen esiintymistiheys vaikuttaa vuosittain 20 prosenttiin kriittisistä sovelluksista ja aiheuttaa liiketoiminnan jatkuvuuden häiriöitä (Gartnerin tutkimus)
• Laitteistoon liittyvä korruptio aiheuttaa 67 % kaikista kiintolevyjen kaatumisista ja järjestelmävioista johtuvista tiedonmenetyksistä, ja 40 % tiedonmenetyksistä johtuu suoraan laitteiston toimintahäiriöistä.
• Ohjelmiston korruptio costs vaihtelevat tuhansista miljooniin dollareihin vakavuudesta ja laajuudesta riippuen, ja 82 % yrityksistä koki suunnittelemattomia käyttökatkoksia, joissa korruptio oli johtava syy

1.2 Miksi säännölliset terveystarkastukset ovat kriittisiä

Ihmiset tarvitsevat säännöllisiä terveystarkastuksia mahdollisten sairauksien havaitsemiseksi varhaisessa vaiheessa. Samoin tietokannat tarvitsevat säännöllisiä terveystarkastuksia:

1. Havaitse mahdollinen korruptio varhaisessa vaiheessa ja puutu siihen viipymättä, estäen ongelmien pahenemisen ja laajenemisen, jotka voisivat johtaa katastrofaalisiin seurauksiin liiketoiminnalle.
2. Varmista, että tietokanta toimii optimaalisella suorituskyvyllä.
3. Cost Ennakoivien tietokannan terveystarkastusten määrä on paljon pienempi kuin reaktiivinen tietojen palautus tietokantakatastrofin jälkeen.

1.3 Johdatus tietokannan eheyskomentoihin

SQL Server tarjoaa useita sisäänrakennettuja komentoja tietokannan kunnon ylläpitämiseen, mukaan lukien DBCC TARKISTUSB toimii m:näost kattava eheystarkistustyökalu saatavilla. Nämä komennot toimivat yhdessä tarkistaakseen tietokannan rakenteen eri osa-alueita yksittäisistä taulukoista koko tietokannan yhtenäisyyteen, muodostaen täydellisen ylläpitostrategian, joka pitää tietosi turvassa ja saatavilla.

2. Mikä on DBCC CHECKDB?

DBCC TARKISTUSB is SQL Serverensisijainen työkalu tietokannan eheyden tarkistamiseen ja vioittumisongelmien tunnistamiseen.

• Se on T-SQL-lauseke, ei graafinen käyttöliittymätyökalu.
• Voit suorittaa sen yleisillä menetelmillä, kuten SQL Server Management Studio (SSMS), SQL Server Agentti, SQLCMD jne.

2.1 Mitä CHECKDB todellisuudessa tarkistaa tietokannassasi

Kun suoritat DBCC CHECKDB -komennon, se suorittaa useita validointikerroksia tietokannan rakenteessa:

• Sivun tarkistussummien varmennus fyysisen vioittumisen ja laitteistoon liittyvien ongelmien havaitsemiseksi
• Indeksin johdonmukaisuuden validointi varmistaakseen asianmukaisen tiedonhaun ja kyselyiden suorituskyvyn
• Allokointirakenteen tarkistukset varmistaaksesi tarkan tilankäytön ja sivujen allokoinnin
• Viiteellisen eheyden tarkastus toisiinsa liittyvien taulukoiden ja viiteavainten välisten suhteiden välillä
• Järjestelmätaulukon johdonmukaisuuden validointi sen varmistamiseksi, SQL Serversisäiset metatiedot pysyvät luotettavina
• Tietosivun linkityksen vahvistus sivuketjun eheyden varmistamiseksi
• Tietokannan rakenteen johdonmukaisuus validoida objektimääritelmiä ja riippuvuuksia

Nämä kattavat tarkistukset kattavat sekä käyttäjätiedot että järjestelmärakenteet, tarjoten täydellisen näkyvyyden tietokannan terveydentilaan.

3. DBCC CHECKDB:n suorittaminen: Vaiheittainen opas

3.1 Edellytykset

Alla on tarkistuslista ennen DBCC CHECKDB -operaation suorittamista:

• Täydellinen tietokannan varmuuskopiointi – Luo täydellinen varmuuskopio ennen eheystarkistusten suorittamista turvaverkkona siltä varalta, että vioittumista havaitaan tai korjaustoimenpiteet ovat tarpeen.
• Oikeat käyttöoikeudet – Tarvitset järjestelmänvalvojan tai db_owner-oikeudet DBCC CHECKDB -komentojen suorittamiseen.
• Riittävät järjestelmäresurssit:
  • Muisti: 25 % tietokannan koosta
  • Väliaikainen tietokannan tila: 10–15 % tietokannan koosta
  • CPU: 50–70 %:n käytettävyys huollon aikana
  • I/O: Odota raskaita lukuoperaatioita
• Tietokannan saavutettavuus – Varmista, että tietokanta on käytettävissä eikä rajoitetussa tilassa, koska CHECKDB vaatii lukuoikeuden kaikille tietokannan sivuille.

3.2 Peruskomento

Most DBCC CHECKDB -komennon perusversio sisältää kolme yleistä variaatiota:

(1) Tarkista nykyinen tietokanta (ei parametreja):

DBCC CHECKDB

(2) Tarkista tietokanta nimen perusteella:

DBCC CHECKDB ('YourDatabaseName')

(3) Tarkista tietokanta tunnuksella:

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

Tämä perustavanlaatuinen komento suorittaa määritetyn tietokannan täydellisen eheystarkistuksen tutkimalla kaikki taulukot, indeksit ja järjestelmärakenteet. Voit jättää lainausmerkit pois tietokannoista, joiden vakionimet eivät sisällä välilyöntejä. Komento suoritetaan, kunnes se on valmis, näyttäen edistymisviestejä ja lopputuloksia. Tämä perussyntaksi toimii täydellisesti pienemmissä tietokannoissa tai silloin, kun sinulla on runsaasti ylläpitoaikaa käytettävissä.

Alla on kuvakaappaus DBCC CHECKDB:n suorittamisesta SQL Server Management Studio (SSMS):

3.3 Täydelliset vaihtoehdot

Alla on kaikki DBCC CHECKDB:n asetukset:

Luokka	Vaihtoehto	Tuotetiedot	DBCC CHECKDB -esimerkki
Korjausvaihtoehdot	REPAIR_REBUILD	Korjaukset ilman tietojen menetystä (esim. indeksien uudelleenrakentaminen)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Ei korjausta. Vain taaksepäin yhteensopiva.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Korjaa kaikki virheet (voi aiheuttaa tietojen menetystä)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Laajuuden valvonta	NOINDEX	Ohittaa klusteroimattomat indeksitarkistukset	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Tarkistaa vain fyysisen tallennustilan eheyden (sivut/tietueet)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Tarkistaa loogiset sarakearvovirheet (esim. virheelliset päivämäärät)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Syvälliset loogiset tarkistukset (indeksoidut näkymät, XML/spatiaaliset indeksit)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Lähdön hallinta	ALL_ERRORMSGS	Näyttää kaikki virheet (oletus: 200 per objekti)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Piilottaa tiedottavat viestit	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Suorituskyky	TABLOCK	Käyttää taulukkolukkoja (vähentää TempDB:n käyttöä, mutta estää kirjoitukset)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Ohittaa rinnakkaisuusasetukset	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Hyödyllisyys	ESTIMATEONLY	Arvioi tarvittavan TempDB-tilan. (ei varsinaista tarkistusta)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Tulosten ymmärtäminen

DBCC CHECKDB tuottaa erilaisia ​​tuloksia riippuen siitä, onnistuuko sen suoritus vai ei. Selitetään ne tarkemmin.

4.1 CHECKDB-suoritus onnistui

Jos DBCC CHECKDB -komennon suoritus onnistuu, se raportoi erityyppisiä tuloksia tietokannan kunnon tilan mukaan.

4.1.1 Ei ongelmia löytynyt

Jos DBCC CHECKDB ei löydä ongelmia, näet seuraavanlaisen tulosteen:

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

Tämä tulos osoittaa, että tietokanta säilyttää täydellisen eheyden kaikissa tarkistetuissa rakenteissa.

4.1.2 Löydetyt korruptiovirheet

Aina kun DBCC CHECKDB havaitsee vioittumisvirheen, se raportoi virheilmoituksen, jonka rakenne on seuraava:
Vakavuustason opas:

• Taso 16-19: Käyttäjän korjattavissa olevat virheet, usein vähäisiä korruptioita
• Taso 20-24: Järjestelmävirheet, vakava korruptio, joka vaatii välitöntä huomiota
• Taso 25: Kohtalokkaita virheitä, tietokantaan ei ehkä pääse käsiksi

Yleisiä virheitä ovat:

• Sivun tarkistussumman virheet (viesti 824)
• Allokointivirheet (viesti 8928)
• Indeksin johdonmukaisuusongelmat (viesti 8964)

Viestirakenteen ymmärtäminen auttaa priorisoimaan toimia ja määrittämään sopivat toipumisstrategiat.

4.1.3 Yleisiä tiedotus- ja varoitusviestejä

Kaikki DBCC CHECKDB -komennon tulokset eivät osoita vakavia ongelmia. Ne voivat myös tuottaa tiedottavia ja varoitusviestejä, kuten:

• Korjauslausunnot – Viestit, jotka ehdottavat korjauskomentoja pienten ongelmien korjaamiseksi
• Varoitusten allokointi – Varoitukset tilan allokoinnista, jotka eivät vaikuta datan käyttöön
• Suorituskykysuositukset – Ehdotuksia indeksin ylläpitoon ja optimointiin
• Tiedotteet – Yleisiä tilanneviestejä, jotka eivät vaadi välittömiä toimia

Nämä viestit tarjoavat arvokasta ylläpito-ohjeistusta ja erottavat toisistaan ​​kriittiset vioittumiset, jotka vaativat välittömiä toimia, ja pienet ongelmat, jotka voidaan korjata säännöllisten huoltovälien aikana.

Esimerkki varoitusviestistä:

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-suorituksen keskeytykset

Jos CHECKDB keskeytyy suorituksensa aikana useista syistä johtuen, se raportoi virheilmoituksen ja lisää virhelokin alla olevalla tilakoodilla:

Osavaltio	Tuotetiedot
0	Virhe numero 8930 ilmeni. Tämä viittaa metatietojen vioittumiseen, joka lopetti DBCC-komennon.
1	Virhe numero 8967 ilmeni. Sisäinen DBCC-virhe.
2	Tietokannan korjauksen hätätilassa tapahtui virhe.
3	Tämä viittaa metatietojen vioittumiseen, joka lopetti DBCC-komennon.
4	Havaittiin väite tai käyttöoikeusrikkomus.
5	Tuntematon virhe, joka lopetti DBCC-komennon, tapahtui.

Esimerkki virheilmoituksesta:

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

Esimerkki virhelokista:

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.

Tällaisessa tapauksessa voit kokeilla vaihtoehtoisia lisäasetuksia, kuten DataNumen SQL Recovery korjataksesi tietokannan vioittumisen.

5. Korruptiovirheiden korjaaminen

5.1 Varmuuskopiointi ja palautus: Turvallisin ratkaisu

Kun DBCC CHECKDB tunnistaa vioittumisvirheitä, palauttaminen puhtaasta varmuuskopiosta on turvallisin ja most luotettava ratkaisu. Tämä lähestymistapa takaa tietojen eheyden ja poistaa samalla taustalla olevat vioittumisen syyt. Ennen palauttamista tarkista varmuuskopion eheys käyttämällä PALAUTA VAIN VAHVISTA komentoja ja harkitse palautusvaihtoehtoja tietyillä ajankohtaisilla tavoilla tietojen menetyksen minimoimiseksi. Dokumentoi vioittumisen yksityiskohdat perussyyanalyysiä varten, sillä laitteisto-ongelmat tai ohjelmistovirheet saattavat vaatia lisähuomiota toistumisen estämiseksi.

5.2 Sivutason korruptioratkaisut

Yksittäisten sivun korruptoitumisen osalta, joka vaikuttaa pieniin dataosiin, SQL Server Enterprise Edition tarjoaa sivunpalautusominaisuuksia, jotka korjaavat tiettyjä vaurioituneita sivuja ilman koko tietokannan palauttamista. Tämä edistynyt tekniikka vaatii täyden palautusmallin ja ajantasaiset lokivarmuuskopiot.

Vaiheittainen sivun palautusprosessi:

1. Tunnista vioittunut sivu CHECKDB-virheilmoituksesta (esim. sivu 1:256)
2. Ota nykyinen lokitiedoston varmuuskopio viimeisimpien tapahtumien tallentamiseksi:

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

3. Palauta vioittunut sivu m:stäost viimeisin täysi varmuuskopio:

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

4. Käytä differentiaalista varmuuskopiointia (jos saatavilla):

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

5. Käytä kaikkia lokivarmuuskopioita järjestyksessä, mukaan lukien juuri luotu:

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. Ota viimeinen lokitiedoston varmuuskopio ja palauta se sivun ajantasaistamiseksi:

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

Vaihtoehto ei-kriittisille tiedoille: Jos vioittuminen vaikuttaa ei-kriittisiin tietoihin, voit viedä muuttumattomat rivit uusiin taulukoihin ennen vioittuneiden rakenteiden uudelleenrakentamista:

-- 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 Indeksin vioittumisen pikakorjaukset

Indeksin vioittuminen reagoi usein hyvin uudelleenrakennusoperaatioihin, jotka luovat indeksirakenteita uudelleen vaikuttamatta pohjana oleviin taulukkotietoihin:

ALTER INDEX ALL ON YourTable REBUILD

Tämä lähestymistapa toimii erityisen hyvin klusteroimattomien indeksien vioittumiseen, koska uudelleenrakentaminen luo indeksisivut uudelleen lähdetaulukon tiedoista, mikä tehokkaasti poistaa vioittumisen säilyttäen samalla kaikki alkuperäiset tiedot.

6. Käytä REPAIR_REBUILD- ja REPAIR_ALLOW_DATA_LOSS-funktioita

Jos kaikki edelliset menetelmät epäonnistuvat tai eivät ole mahdollisia, voit korjata tietokannan REPAIR_REBUILD- ja REPAIR_ALLOW_DATA_LOSS-asetuksilla.

6.1 KORJAA_UUDELLEENRAKENNA (Turvallisempi vaihtoehto):

• Käyttää: Indeksin korruptio ja pienet allokointivirheet
• Tietojen turvallisuus: Yrittää korjata korruptiota poistamatta tietoja
• Riskitaso: Matala – ei odotettavissa olevaa datan menetystä
• Tyypillisiä skenaarioita: Klusteroimattoman indeksin vioittuminen, pieniä metatieto-ongelmia
• Komentoesimerkki: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Viimeinen keino):

• Käyttää: Vakava korruptio, kun varmuuskopioita ei ole saatavilla
• Tietojen turvallisuus: Saattaa poistaa vioittuneita tietoja tietokannan toiminnallisuuden palauttamiseksi
• Riskitaso: Korkea – pysyvä tietojen menetys mahdollinen
• Tyypillisiä skenaarioita: Sivun vioittuminen, järjestelmätaulukon vaurioituminen, allokointiketjun virheet
• Komentoesimerkki: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Parhaat käytännöt molemmille vaihtoehdoille:

• Testaa aina korjaustoiminnot tietokantakopioille mahdollisuuksien mukaan
• Varmuuskopioi aina ennen näiden vaihtoehtojen suorittamista
• Dokumentoi kaikki muutokset vaatimustenmukaisuuden ja vianmäärityksen vuoksi
• Aseta tietokanta yhden käyttäjän tilaan ennen korjaustöiden aloittamista

6.4 Korjaustulokset

6.4.1 Repair Succeeds with Data Loss

Joskus korjaus REPAIR_ALLOW_DATA_LOSS option will succeed, but some data is lost korjauksen jälkeen.

Alla on esimerkkiviesti:

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.

Näyte

SQL Server versio	Viallinen MDF-tiedosto	MDF-tiedoston korjannut DataNumen SQL Recovery
SQL Server 2014	Error7MDF (100 tietuetta lost (ja REPAIR_ALLOW_DATA_LOSS)	Virhe7_korjattu.mdf (Vain yksi tietue lost (ja REPAIR_ALLOW_DATA_LOSS)

DBCC korjaa tietokannan hylkäämällä joitakin vaurioituneita tietueita, mutta todellisuudessa most niistä voidaan ottaa talteen DataNumen SQL Recovery.

6.4.2 Repair Fails – Consider Professional Solution

Jos korjaus epäonnistuu, se antaa virheilmoituksen.

Alla on joitakin esimerkkejä:

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.
DBCC results for ‘SalesDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘SalesDatabase’.
Msg 7909, Level 20, State 1, Line 4
The emergency-mode repair failed.You must restore from backup.

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.
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 824, Level 24, State 2, Line 2
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:160; actual 0:41). It occurred during a read of page (1:160) in database ID 39 at offset 0x00000000140000 in file ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.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.

In these scenarios, you need to use a professional solution such as DataNumen SQL Recovery to fix your database.

Esimerkkitiedostot

SQL Server versio	Viallinen MDF-tiedosto	MDF-tiedoston korjannut DataNumen SQL Recovery
SQL Server 2014	Virhe3.mdf (CHECKDB palauttaa viestin 5028)	Virhe3_korjattu.mdf
SQL Server 2014	Error8MDF (CHECKDB palauttaa viestin 5125)	Error8_fixed.mdf
SQL Server 2014	Virhe9.mdf (CHECKDB palauttaa viestin 3313)	Virhe9_korjattu.mdf

7. Parhaat käytännöt

7.1 Säännöllisten CHECKDB-operaatioiden ajoittaminen

Toteuta viikoittainen DBCC CHECKDB -suoritus kriittisille tuotantotietokannoille ja päivittäiset tarkastukset paljon tapahtuville järjestelmille. Aikatauluta toiminnot vähäisen käytön aikoina suorituskykyyn kohdistuvien vaikutusten minimoimiseksi ja harkitse vuorottelua täysien tarkistusten ja PHYSICAL_ONLY-vaihtoehtojen välillä tietokannan koon ja ylläpitoikkunoiden perusteella. Automatisoi aikataulutus SQL Server Agentti varmistaa yhdenmukaisen suorituksen ja tarjoaa samalla keskitettyjä valvonta- ja hälytysominaisuuksia.

7.2 Suorituskykyyn vaikuttavien tekijöiden hallinta

DBCC CHECKDB -toiminnot kuluttavat merkittävästi järjestelmäresursseja, mikä voi vaikuttaa samanaikaiseen käyttäjien toimintaan. Valvo suorittimen käyttöastetta, muistin kulutusta ja levyn I/O:ta tarkistusten aikana ymmärtääksesi suorituskykyyn vaikuttavia malleja. Harkitse NOINDEX-asetusten käyttöä rutiinitarkistuksissa ja varaa täysi validointi kuukausittaisiin ylläpitoaikoihin. Ota käyttöön kyselyn aikakatkaisulaajennuksia ja käyttäjien viestintästrategioita eheystarkistusten odotusten hallitsemiseksi.

7.3 Huoltoikkunan suunnittelu

Koordinoi DBCC CHECKDB -ajoitusta muiden ylläpitotoimien, kuten varmuuskopiointien, indeksien uudelleenrakentamisen ja tilastopäivitysten, kanssa. Vältä päällekkäisiä resursseja kuluttavia toimintoja, jotka voivat aiheuttaa suorituskyvyn heikkenemistä tai aikakatkaisuongelmia. Suunnittele ylläpitoikkunat tietokannan koon kasvuennusteiden perusteella varmistaen riittävästi aikaa täydelliseen eheyden varmentamiseen tietomäärien kasvaessa.

7.4 Automaattinen valvonta ja hälytysjärjestelmä

Configure SQL Server Agenttihälytykset ilmoittavat järjestelmänvalvojille välittömästi, kun DBCC CHECKDB tunnistaa korruptiota. Toteuta lokitietojen jäsennysratkaisuja, jotka poimivat ja luokittelevat eheystarkistusten tulokset, mikä mahdollistaa trendianalyysin ja ennakoivan ongelmien tunnistamisen. Luo eskalointimenettelyt, jotka määrittelevät vasteajat ja vastuuhenkilöt eri korruptiovakavuustasoille.

8. DBCC CHECKTABLE: Kevyt vaihtoehto

8.1 Milloin CHECKTABLE-funktiota käytetään CHECKDB:n sijaan

DBCC CHECKTABLE tarjoaa kohdennetun eheystarkistuksen yksittäisille taulukoille, joten se sopii erinomaisesti tartiettyjen tietokantaobjektien vianmääritys ja ylläpito. Käytä CHECKTABLE-menetelmää tutkiessasi tiettyjen taulukoiden suorituskykyongelmia, validoidessasi kriittisiä liiketoimintataulukoita koko tietokannan tarkistusten välillä tai kun aikarajoitukset estävät tietokannan täydellisen validoinnin. Tämä lähestymistapa osoittautuu erityisen arvokkaaksi suurissa tietokannoissa, joissa täydet CHECKDB-toiminnot ylittävät käytettävissä olevat ylläpitoikkunat.

8.2 DBCC CHECKTABLE -syntaksi ja esimerkkejä

CHECKTABLE-peruskomento tarhakee tiettyjä taulukoita:

DBCC CHECKTABLE('YourTable')

Kuten CHECKDB, CHECKTABLE tukee useita vaihtoehtoja, kuten NOINDEX suorituskyvyn optimointiin ja korjausparametreja vioittumisen korjaamiseen. Voit myös määrittää skeemien nimet taulukoiden tarkkaa tunnistamista varten:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Tämä targeted-lähestymistapa mahdollistaa tarkan eheyden varmentamisen samalla, kun järjestelmän suorituskyky säilyy toimistoaikoina.

8.3 Suurten tietokantojen suorituskykyedut

CHECKTABLE-operaatiot suoritetaan huomattavasti nopeammin kuin täydelliset tietokannan tarkistukset, mikä mahdollistaa kriittisten taulukoiden eheyden tiheämmän tarkistamisen. Tämä lähestymistapa mahdollistaa tärkeiden liiketoimintataulukoiden päivittäisen validoinnin ja varaa samalla kattavat CHECKDB-operaatiot viikoittaisille tai kuukausittaisille aikatauluille. Vähentynyt resurssien kulutus tekee CHECKTABLEsta sopivan tuotantoympäristön suoritukseen ja minimoi käyttäjien vaikutuksen.

9. Kun CHECKDB epäonnistuu

DBCC CHECKDB epäonnistuu useissa tilanteissa, mukaan lukien:

• DBCC CHECKDB -suoritus päättyy epänormaalisti
• DBCC CHECKDB -suoritus onnistuu, mutta korjausvaihtoehdot tietokannan korjaus epäonnistuu.

Näissä tilanteissa tarvitsemme ammattimaisemman työkalun auttamaan meitä korjaamaan tietokannan vioittuneet kohdat.

9.1 Johdatus DataNumen SQL Recovery

DataNumen SQL Recovery tarjoaa edistyneempiä ominaisuuksia:

• Paras palautumisaste alalla.
• Palauta vakavasti vioittuneet tietokantatiedostot.
• Palauta kaikki tietokantaobjektit, mukaan lukien taulukot, indeksit, näkymät, käynnistimet, säännöt ja oletusarvot.
• Palauta tallennetut proseduurit, skalaarifunktiot, rivin taulukkoarvoiset funktiot ja monilauseiset taulukkoarvoiset funktiot.
• Palauta pysyvästi poistetut tiedot.
• Pura salattujen objektien salaus kohdassa SQL Server tietokantoja.
• Korjaa MDF-tiedostot eränä.
• Kattavat korjausvaihtoehdot.
• Edistynyt kirjaus ja raportointi.
• Tuki kaikille SQL Server versiot.
• Teknisen tuen saatavuus
• Säännölliset päivitykset ja parannukset

9.2 Onnistumisprosentin vertailu

Toipumisen onnistumisprosentit vaihtelevat merkittävästi:

• DBCC CHECKDB & CHECKTABLE: 1.27% keskimääräinen palautumisaste
• DataNumen: 92.6% palautumisaste

Alla on täydellinen kilpailuvertailu:

9.3 Vakavasta korruptiosta toipuminen

Kehittyneet ominaisuudet vakaviin tapauksiin:

• Toipuminen fyysisesti vahingoittuneesta varastosta
• Palautus alustetuista asemista tai kaatuneista järjestelmistä
• Palauta levykuvista, varmuuskopiotiedostoista, virtuaalikoneen levytiedostoista, tempostarary-tiedostoja jne.

9.4 Milloin harkita ammattimaisia ​​ratkaisuja

• Ei viimeaikaista varmuuskopiointia saatavilla
• DBCC CHECKDB epäonnistuu
• Vakavat korruptioskenaariot
• Kriittisen liiketoimintadatan käsittely
• Kun aika on kriittinen
• Kun maksimaalinen palautuminen on välttämätöntä

10. UKK

11. Päätelmä

11.1 Yhteenveto avainkohdista

11.1.1 Keskeisten DBCC CHECKDB -komentojen yhteenveto

Hallitse DBCC CHECKDB:n perussyntaksi kattavaa tietokannan tarkistusta varten, käytä NOINDEX- ja PHYSICAL_ONLY-asetuksia suorituskyvyn optimointiin ja ymmärrä CHECKTABLE-funktion target-taulukon varmennus. Nämä perustavanlaatuiset komennot muodostavat ennakoivan tietokannan ylläpidon perustan, mahdollistaen vioittumisen varhaisen havaitsemisen ja systemaattisen eheyden valvonnan.

11.1.2 Muistutus tärkeistä parhaista käytännöistä

Pidä aina ajan tasalla olevat varmuuskopiot ennen eheystarkistusten suorittamista, ajoita säännölliset CHECKDB-toiminnot tietokannan kriittisyyden perusteella ja ota käyttöön automaattinen valvonta välittömien vioittumishälytysten saamiseksi. Muista, että säännöllisen valvonnan avulla tapahtuva ennaltaehkäisy on parempi kuin reaktiiviset lähestymistavat, ja ammattimaiset palautusratkaisut tarjoavat arvokkaita varmuuskopiointivaihtoehtoja, kun vakiotyökalut osoittautuvat riittämättömiksi.

11.2 Milloin käyttää DBCC CHECKDB:tä vs. edistyneitä ratkaisuja

Käytä DBCC CHECKDB:tä rutiininomaiseen eheyden valvontaan ja pienten vioittumisratkaisujen korjaamiseen ja varaa ammattimaiset palautustyökalut vakaviin vioittumistilanteisiin, jotka ylittävät sisäänrakennetut korjausominaisuudet. Päätöksentekokehyksen tulisi ottaa huomioon varmuuskopioiden saatavuus, tietojen kriittisyys, aikarajoitukset ja vioittumisen vakavuus. Menestyksekkäät tietokannan ylläpitäjät yhdistävät säännöllisen CHECKDB-valvonnan kattaviin varmuuskopiointistrategioihin ja edistyneiden palautusvaihtoehtojen tuntemukseen, kun vakiomenetelmät osoittautuvat riittämättömiksi.

12. Viitteet

1. Microsoft Learn. ”DBCC CHECKDB (Transact-SQL).” SQL Server DokumentaatioMicrosoft 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:n raportoimien tietokannan yhtenäisyysvirheiden vianmääritys.” SQL Server DokumentaatioMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors