DBCC CHECKDB (Transact-SQL)

• 14.12.2017
• 22 minuuttia aikaa lukea
• • p
  • M

  .

  • m
  • M
  • P
  • +3

Käytetään: SQL Server (kaikki tuetut versiot) Azure SQL Database

Tarkistaa määritetyn tietokannan kaikkien objektien loogisen ja fyysisen eheyden suorittamalla seuraavat toiminnot:

• Suorittaa DBCC CHECKALLOC tietokannassa.
• Suorittaa DBCC CHECKTABLE jokaiselle tietokannan taululle ja näkymälle.
• Suorittaa DBCC CHECKCATALOG tietokannalle.
• Valvoa tietokannan jokaisen indeksoidun näkymän sisältö.
• Varmentaa linkkitason yhdenmukaisuuden taulukon metatietojen ja tiedostojärjestelmän hakemistojen ja tiedostojen välillä, kun varbinary(max)-tietoja tallennetaan tiedostojärjestelmään FILESTREAMin avulla.
• Varmentaa Service Brokerin tiedot tietokannassa.

Tämä tarkoittaa sitä, että DBCC CHECKALLOC-, DBCC CHECKTABLE- tai DBCC CHECKCATALOG-käskyjä ei tarvitse suorittaa erillään DBCC CHECKDB:n käskyistä. Tarkempia tietoja näiden komentojen suorittamista tarkistuksista on näiden komentojen kuvauksissa.

Transact-SQL-syntaksikonventiot

Syntaksi

DBCC CHECKDB ) ] } ] ] 

Argumentit

database_name | database_id | 0
On sen tietokannan nimi tai ID, jonka eheystarkastukset suoritetaan. Jos sitä ei määritetä tai jos 0 on määritetty, käytetään nykyistä tietokantaa. Tietokannan nimien on oltava tunnuksia koskevien sääntöjen mukaisia.

NOINDEX
Määrittää, että käyttäjätaulujen ei-klusteroitujen indeksien intensiivisiä tarkistuksia ei suoriteta. Tämä vähentää yleistä suoritusaikaa. NOINDEX ei vaikuta järjestelmätaulukoihin, koska eheystarkastukset tehdään aina järjestelmätaulukoiden indekseille.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Määrittää, että DBCC CHECKDB korjaa löydetyt virheet. Käytä REPAIR-asetuksia vain viimeisenä keinona. Määritetyn tietokannan on oltava yhden käyttäjän tilassa, jotta voit käyttää jotakin seuraavista korjausasetuksista.

REPAIR_ALLOW_DATA_LOSS
Yritetään korjata kaikki ilmoitetut virheet. Nämä korjaukset voivat aiheuttaa jonkin verran tietojen menetystä.

REPAIR_FAST
Pitää yllä syntaksia vain taaksepäin yhteensopivuuden vuoksi. Mitään korjaustoimia ei suoriteta.

REPAIR_REBUILD
Toteuttaa korjauksia, joissa ei ole mahdollisuutta tietojen menetykseen. Tämä voi sisältää nopeita korjauksia, kuten puuttuvien rivien korjaaminen ei-klusteroidussa indeksissä, ja aikaa vievämpiä korjauksia, kuten indeksin uudelleenrakentaminen.
Tämä argumentti ei korjaa virheitä, jotka koskevat FILESTREAM-tietoja.

ALL_ERRORMSGS
Näyttää kaikki raportoidut virheet kohteittain. Kaikki virheilmoitukset näytetään oletusarvoisesti. Tämän vaihtoehdon määrittämisellä tai pois jättämisellä ei ole vaikutusta. Virheilmoitukset lajitellaan objektin ID:n mukaan, lukuun ottamatta tempdb-tietokannasta tuotettuja viestejä.

EXTENDED_LOGICAL_CHECKS
Jos yhteensopivuustaso on 100 ( SQL Server 2008) tai korkeampi, suorittaa loogiset yhdenmukaisuustarkastukset indeksoidulle näkymälle, XML-indekseille ja paikkatietoindekseille, jos niitä on.
Lisätietoja on kohdassa Loogisten johdonmukaisuustarkastusten suorittaminen indekseille osassa Huomautuksia myöhemmin tässä aiheessa.

NO_INFOMSGS
Edistää kaikki tiedotusviestit.

TABLOCK
Käynnistää DBCC CHECKDB:n hankkimaan lukituksia tietokannan sisäisen tilannekuvan sijaan. Tämä sisältää tietokannan lyhytaikaisen yksinoikeuslukon (X). TABLOCK saa DBCC CHECKDB:n toimimaan nopeammin raskaasti kuormitetussa tietokannassa, mutta vähentää tietokannan käytettävissä olevaa samanaikaisuutta DBCC CHECKDB:n ollessa käynnissä.

ESTIMATEONLY
Näyttää arvioidun tempdb-tilan määrän, joka tarvitaan DBCC CHECKDB:n suorittamiseen kaikilla muilla määritetyillä asetuksilla. Varsinaista tietokannan tarkistusta ei suoriteta.

PHYSICAL_ONLY
Rajoittaa tarkistuksen sivun ja tietueiden otsikoiden fyysisen rakenteen eheyteen ja tietokannan jakokonsistenssiin. Tämä tarkistus on suunniteltu tarjoamaan tietokannan fyysisen johdonmukaisuuden pieni yleistarkistus, mutta se voi myös havaita repeytyneet sivut, tarkistussummavirheet ja yleiset laitteistoviat, jotka voivat vaarantaa käyttäjän tiedot.
DBCC CHECKDB:n täysi suoritus voi kestää huomattavasti kauemmin kuin aiempien versioiden suoritus. Tämä käyttäytyminen johtuu siitä, että:

• Loogiset tarkistukset ovat kattavampia.
• Joidenkin tarkistettavien rakenteiden taustalla olevat rakenteet ovat monimutkaisempia.
• Monia uusia tarkistuksia on otettu käyttöön uusien ominaisuuksien sisällyttämiseksi.
  Sentähden PHYSICAL_ONLY-vaihtoehdon käyttäminen voi aiheuttaa paljon lyhyemmän suoritusajan DBCC CHECKDB:lle suurissa tietokannoissa, ja sitä suositellaan käytettäväksi usein tuotantojärjestelmissä. Suosittelemme edelleen, että DBCC CHECKDB:n täysi ajo suoritetaan määräajoin. Näiden ajojen tiheys riippuu yksittäisten yritysten ja tuotantoympäristöjen erityisistä tekijöistä.
  Tämä argumentti merkitsee aina NO_INFOMSGS eikä se ole sallittu minkään korjausvaihtoehdon kanssa.

DATA_PURITY
Saattaa DBCC CHECKDB:n tarkistamaan tietokannan sellaisten sarakearvojen varalta, jotka eivät ole kelvollisia tai jotka ovat alueen ulkopuolella. DBCC CHECKDB havaitsee esimerkiksi sarakkeet, joiden päivämäärä- ja aika-arvot ovat suurempia tai pienempiä kuin datetime-tietotyypin hyväksyttävä vaihteluväli, tai desimaali- tai likimääräisen numeerisen tietotyypin sarakkeet, joiden asteikko- tai tarkkuusarvot eivät ole kelvollisia.
Sarakkeiden arvojen eheystarkistukset ovat oletusarvoisesti käytössä eivätkä vaadi DATA_PURITY-valintaa. SQL Serverin aiemmista versioista päivitetyissä tietokannoissa sarakearvojen eheystarkistuksia ei oteta oletusarvoisesti käyttöön ennen kuin DBCC CHECKDB WITH DATA_PURITY on suoritettu tietokannassa virheettömästi. Tämän jälkeen DBCC CHECKDB tarkistaa sarakearvojen eheyden oletusarvoisesti. Lisätietoja siitä, miten CHECKDB:hen saattaa vaikuttaa tietokannan päivittäminen SQL Serverin aiemmista versioista, on tämän aiheen myöhemmässä kohdassa Huomautuksia.

Tämän vaihtoehdon raportoimia virheitä ei voi korjata DBCC:n korjausvaihtoehdoilla. Tietoja näiden virheiden manuaalisesta korjaamisesta on Knowledge Base -artikkelissa 923247: DBCC-virheen 2570 vianmääritys SQL Server 2005:ssä ja uudemmissa versioissa.

MAXDOP
Käytetään seuraavissa tapauksissa: SQL Server ( SQL Server 2014 (12.x) SP2 ja uudemmat).

Operrides the max degree of parallelism configuration option of sp_configure for the statement. MAXDOP voi ylittää sp_configure-asetuksella määritetyn arvon. Jos MAXDOP ylittää Resource Governorilla määritetyn arvon, SQL Serverin tietokantamoottori käyttää kohdassa ALTER WORKLOAD GROUP kuvattua Resource Governorin MAXDOP-arvoa. Kaikkia max degree of parallelism -määritysvaihtoehdon kanssa käytettyjä semanttisia sääntöjä sovelletaan, kun käytät MAXDOP-kyselyvihjettä. Lisätietoja on kohdassa Palvelimen max degree of parallelism -määritysvaihtoehdon määrittäminen.

Huomautukset

DBCC CHECKDB ei tutki käytöstä poistettuja indeksejä. Lisätietoja käytöstä poistetuista indekseistä on kohdassa Indeksien ja rajoitusten poistaminen käytöstä.

Jos käyttäjän määrittelemä tyyppi on merkitty tavujärjestetyksi, käyttäjän määrittelemälle tyypille saa olla vain yksi sarjastus. Se, ettei tavujärjestyksessä järjestetyillä käyttäjän määrittelemillä tyypeillä ole yhdenmukaista sarjallistamista, aiheuttaa virheen 2537, kun DBCC CHECKDB suoritetaan. Lisätietoja on kohdassa Käyttäjämääriteltyjä tyyppejä koskevat vaatimukset.

Koska Resurssitietokantaa voi muokata vain yhden käyttäjän tilassa, DBCC CHECKDB -komentoa ei voi suorittaa sille suoraan. Kun DBCC CHECKDB suoritetaan master-tietokantaa vastaan, toinen CHECKDB suoritetaan kuitenkin sisäisesti myös Resource-tietokannassa. Tämä tarkoittaa, että DBCC CHECKDB voi palauttaa ylimääräisiä tuloksia. Komento palauttaa ylimääräisiä tulosjoukkoja, kun asetuksia ei ole asetettu tai kun joko PHYSICAL_ONLY– tai ESTIMATEONLY-asetus on asetettu.

SQL Server 2005 (9.x) SP2:sta alkaen DBCC CHECKDB:n suorittaminen ei enää tyhjennä SQL Server -instanssin suunnitelmavälimuistia. Ennen SQL Server 2005 (9.x) SP2:ta DBCC CHECKDB:n suorittaminen tyhjentää suunnitelmavälimuistin. Suunnitelmavälimuistin tyhjentäminen aiheuttaa kaikkien myöhempien suoritussuunnitelmien uudelleenkompiloimisen ja voi aiheuttaa äkillisen, tilapäisen kyselyn suorituskyvyn heikkenemisen.

Loogisten johdonmukaisuustarkastusten suorittaminen indekseille

Logisten johdonmukaisuustarkastusten suorittaminen indekseille vaihtelee tietokannan yhteensopivuustason mukaan seuraavasti:

• Jos yhteensopivuustaso on 100 (SQL Server 2008) tai korkeampi:
• Jollei NOINDEX:tä ole määritetty, DBCC CHECKDB suorittaa sekä fyysiset että loogiset johdonmukaisuustarkastukset yksittäiselle taululle ja kaikille sen ei-klusteroiduille indekseille. XML-indekseille, spatiaalisille indekseille ja indeksoiduille näkymille suoritetaan kuitenkin oletusarvoisesti vain fyysiset yhdenmukaisuustarkastukset.
• Jos WITH EXTENDED_LOGICAL_CHECKS on määritetty, loogiset tarkastukset suoritetaan indeksoidulle näkymälle, XML-indekseille ja spatiaalisille indekseille, jos niitä on. Oletusarvoisesti fyysiset yhdenmukaisuustarkastukset suoritetaan ennen loogisia yhdenmukaisuustarkastuksia. Jos myös NOINDEX on määritetty, suoritetaan vain loogiset tarkistukset.

Nämä loogiset yhdenmukaisuustarkistukset ristiintarkastavat indeksikohteen sisäisen indeksitaulukon sen käyttäjän taulun kanssa, johon se viittaa. Poikkeavien rivien löytämiseksi rakennetaan sisäinen kysely, jolla suoritetaan sisäisen ja käyttäjän taulukon täydellinen leikkaus. Tämän kyselyn suorittamisella voi olla erittäin suuri vaikutus suorituskykyyn, eikä sen etenemistä voida seurata. Siksi suosittelemme, että määrität WITH EXTENDED_LOGICAL_CHECKS vain, jos epäilet indeksiongelmia, jotka eivät liity fyysiseen korruptoitumiseen, tai jos sivutason tarkistussummat on kytketty pois päältä ja epäilet saraketason laitteistokorruptoitumista.

• Jos indeksi on suodatettu indeksi, DBCC CHECKDB suorittaa yhdenmukaisuustarkistuksia tarkistaakseen, että indeksin merkinnät täyttävät suodatuspredikaatin.
• Jos yhteensopivuustaso on 90 tai vähemmän, ellei NOINDEX ole määritetty, DBCC CHECKDB suorittaa sekä fyysiset että loogiset yhdenmukaisuustarkastukset yksittäiselle taululle tai indeksoidulle näkymälle ja kaikille sen ei-klusteroiduille ja XML-indekseille. Paikkatietoindeksejä ei tueta.
• Alkaen SQL Server 2016:sta persistoitujen laskennallisten sarakkeiden, UDT-sarakkeiden ja suodatettujen indeksien lisätarkistuksia ei oletusarvoisesti suoriteta kalliiden lausekkeiden arviointien välttämiseksi. Tämä muutos lyhentää huomattavasti CHECKDB:n kestoa näitä objekteja sisältäviä tietokantoja vastaan. Näiden objektien fyysiset yhdenmukaisuustarkastukset suoritetaan kuitenkin aina loppuun. Vain silloin, kun EXTENDED_LOGICAL_CHECKS-vaihtoehto on määritetty, lausekearvioinnit suoritetaan jo olemassa olevien loogisten tarkistusten (indeksoitu näkymä, XML-indeksit ja spatiaaliset indeksit) lisäksi osana EXTENDED_LOGICAL_CHECKS-vaihtoehtoa.

Tietokannan yhteensopivuustason selvittäminen

• Tietokannan yhteensopivuustason tarkasteleminen tai muuttaminen

Tietokannan sisäinen tilannekuva

DBCC CHECKDB käyttää tietokannan sisäistä tilannekuvaa tapahtumakonsistenssiin, jota tarvitaan näiden tarkistusten suorittamiseen. Näin estetään esto- ja samanaikaisuusongelmat, kun näitä komentoja suoritetaan. Lisätietoja on kohdassa Näytä tietokannan tilannekuvan harvennetun tiedoston koko (Transact-SQL) ja DBCC:n (Transact-SQL) kohdassa DBCC Internal Database Snapshot Usage. Jos tilannekuvaa ei voida luoda tai TABLOCK on määritetty, DBCC CHECKDB hankkii lukituksia tarvittavan johdonmukaisuuden saavuttamiseksi. Tässä tapauksessa tarvitaan yksinoikeudellinen tietokantalukko allokointitarkistusten suorittamiseen ja jaetut taulukkolukot taulukkotarkistusten suorittamiseen.DBCC CHECKDB epäonnistuu, kun se suoritetaan masteria vastaan, jos sisäistä tietokannan tilannekuvaa ei voida luoda.DBCC CHECKDB:n suorittaminen tempdb:tä vastaan ei suorita allokointi- tai luettelotarkistuksia, ja sen on hankittava jaetut taulukkolukot taulukkotarkistusten suorittamiseksi. Tämä johtuu siitä, että suorituskykysyistä tietokannan tilannekuvat eivät ole käytettävissä tempdb:ssä. Tämä tarkoittaa, että vaadittua transaktiokonsistenssia ei voida saavuttaa.Microsoft SQL Server 2012:ssa tai aiemmassa SQL Server -versiossa saatat saada virheilmoituksia, kun suoritat DBCC CHECKDB -komennon sellaiselle tietokannalle, jonka tiedostot sijaitsevat ReFS-muotoisessa tietueessa. Lisätietoja on Knowledge Base -artikkelissa 2974455: DBCC CHECKDB:n käyttäytyminen, kun SQL Server -tietokanta sijaitsee ReFS-tietueella.

FILESTREAM-tietojen tarkistaminen ja korjaaminen

Kun FILESTREAM on otettu käyttöön tietokannassa ja taulussa, voit tallentaa tiedostojärjestelmään valinnaisesti varbinary(max) binary large objects (BLOB) -objekteja. Kun käytät DBCC CHECKDB:tä tietokannassa, joka tallentaa BLOB-muistitiedostoja tiedostojärjestelmään, DBCC tarkistaa linkkitason yhdenmukaisuuden tiedostojärjestelmän ja tietokannan välillä.Jos esimerkiksi taulussa on varbinary(max)-sarake, joka käyttää FILESTREAM-attribuuttia, DBCC CHECKDB tarkistaa, että tiedostojärjestelmän hakemistojen ja tiedostojen sekä taulukon rivien, sarakkeiden ja sarakearvojen välillä on yksi yhteen -mappaus. DBCC CHECKDB voi korjata korruption, jos määrität REPAIR_ALLOW_DATA_LOSS-vaihtoehdon. FILESTREAM-korruption korjaamiseksi DBCC poistaa kaikki taulukon rivit, joista puuttuu tiedostojärjestelmän tietoja.

Parhaat käytännöt

Suosittelemme, että käytät PHYSICAL_ONLY-vaihtoehtoa, jos sitä käytetään usein tuotantojärjestelmissä. PHYSICAL_ONLY:n käyttäminen voi lyhentää huomattavasti DBCC CHECKDB:n suoritusaikaa suurissa tietokannoissa. Suosittelemme myös ajamaan ajoittain DBCC CHECKDB:n ilman vaihtoehtoja. Se, kuinka usein nämä ajot kannattaa suorittaa, riippuu yksittäisistä yrityksistä ja niiden tuotantoympäristöistä.

Objektien tarkistaminen rinnakkain

Oletusarvoisesti DBCC CHECKDB suorittaa objektien tarkistamisen rinnakkain. Kyselyprosessori määrittää rinnakkaisuuden asteen automaattisesti. Rinnakkaisuuden enimmäisaste määritetään aivan kuten rinnakkaiskyselytkin. Jos haluat rajoittaa DBCC-tarkistukseen käytettävissä olevien prosessoreiden enimmäismäärää, käytä sp_configure-ohjelmaa. Lisätietoja on kohdassa Rinnakkaisuuden enimmäisasteen määrittäminen palvelimen määritysvaihtoehto. Rinnakkaistarkistus voidaan poistaa käytöstä käyttämällä trace-lippua 2528. Lisätietoja on kohdassa Jäljitysliput (Transact-SQL).

DBCC-virheilmoitusten ymmärtäminen

Komennon DBCC CHECKDB päätyttyä SQL Serverin virhelokiin kirjoitetaan viesti. Jos DBCC-komento suoritetaan onnistuneesti, viestissä ilmoitetaan onnistuminen ja komennon suoritusaika. Jos DBCC-komento pysähtyy ennen tarkistuksen suorittamista virheen vuoksi, viestissä ilmoitetaan, että komento keskeytettiin, tilaarvo ja aika, jonka komento suoritettiin. Seuraavassa taulukossa luetellaan ja kuvataan tilaarvot, jotka voidaan sisällyttää viestiin.

Tila	Kuvaus
0	Virhe numero 8930 tuli esiin. Tämä viittaa metatiedoissa olleeseen korruptioon, joka lopetti DBCC-komennon.
1	Error number 8967 was raised. Tapahtui sisäinen DBCC-virhe.
2	Tietokannan korjauksessa hätätilassa tapahtui virhe.
3	Tämä ilmaisee metatiedoissa olevaa korruptiota, joka lopetti DBCC-komennon.
4	Havaittiin asserttitietoja tai käyttöoikeuksia koskeva rikkomus.
5	Esiintyi tuntematon virhe, joka lopetti DBCC-komennon.

Virheraportointi

Dumppitiedosto (SQLDUMP*nnnn*.txt) luodaan SQL Serverin LOG-hakemistoon aina, kun DBCC CHECKDB havaitsee korruptoitumisvirheen. Kun Feature Usage -tiedonkeruu- ja Error Reporting -ominaisuudet on otettu käyttöön SQL Server -instanssissa, tiedosto välitetään automaattisesti Microsoftille. Kerättyjä tietoja käytetään SQL Serverin toimintojen parantamiseen. dumppitiedosto sisältää DBCC CHECKDB -komennon tulokset ja muita diagnostiikkatulosteita. Käyttöoikeus on rajoitettu SQL Server -palvelutilille ja sysadmin-roolin jäsenille. Oletusarvoisesti sysadmin-rooliin kuuluvat kaikki Windows BUILTIN\Administrators -ryhmän ja paikallisen järjestelmänvalvojan ryhmän jäsenet. DBCC-komento ei epäonnistu, jos tiedonkeruuprosessi epäonnistuu.

Virheiden ratkaiseminen

Jos DBCC CHECKDB raportoi virheitä, suosittelemme tietokannan palauttamista tietokannan varmuuskopiosta sen sijaan, että suorittaisit REPAIR-komennon jollakin REPAIR-vaihtoehdolla. Jos varmuuskopiota ei ole olemassa, korjauksen suorittaminen korjaa ilmoitetut virheet. Käytettävä korjausvaihtoehto määritetään raportoitujen virheiden luettelon lopussa. Virheiden korjaaminen REPAIR_ALLOW_DATA_LOSS-vaihtoehdon avulla saattaa kuitenkin vaatia joidenkin sivujen ja siten joidenkin tietojen poistamista.

Joskus tietokantaan saatetaan syöttää arvoja, jotka eivät ole sarakkeen tietotyypin perusteella kelvollisia tai jotka ovat alueen ulkopuolella. DBCC CHECKDB voi havaita sarakkeen arvot, jotka eivät ole kelvollisia kaikille sarakkeen tietotyypeille. Siksi DBCC CHECKDB:n suorittaminen DATA_PURITY-valinnalla tietokannoissa, jotka on päivitetty SQL Serverin aiemmista versioista, saattaa paljastaa jo olemassa olevia sarakearvovirheitä. Koska SQL Server ei voi korjata näitä virheitä automaattisesti, sarakearvo on päivitettävä manuaalisesti. Jos CHECKDB havaitsee tällaisen virheen, CHECKDB palauttaa varoituksen, virhenumeron 2570 ja tiedot, joiden avulla voidaan tunnistaa kyseinen rivi ja korjata virhe manuaalisesti.

Korjaus voidaan suorittaa käyttäjän tapahtuman alla, jotta käyttäjä voi ottaa tehdyt muutokset takaisin. Jos korjaukset palautetaan, tietokanta sisältää edelleen virheitä, ja se on palautettava varmuuskopiosta. Varmuuskopioi tietokanta sen jälkeen, kun korjaukset on suoritettu.

Virheiden ratkaiseminen tietokannan hätätilassa

Kun tietokanta on asetettu hätätilaan ALTER DATABASE -lausekkeella, DBCC CHECKDB voi suorittaa tietokannalle joitakin erityiskorjauksia, jos REPAIR_ALLOW_DATA_LOSS-vaihtoehto on määritetty. Nämä korjaukset voivat mahdollistaa sen, että tavallisesti korjauskelvottomat tietokannat voidaan palauttaa verkkoon fyysisesti yhdenmukaiseen tilaan. Näitä korjauksia tulisi käyttää viimeisenä keinona ja vain silloin, kun tietokantaa ei voida palauttaa varmuuskopiosta. Kun tietokanta asetetaan hätätilaan, tietokanta merkitään READ_ONLY-merkinnällä, lokitus poistetaan käytöstä ja käyttöoikeus rajoitetaan kiinteän palvelinroolin sysadmin-jäseniin.

Kun tietokanta on hätätilassa ja DBCC CHECKDB suoritetaan REPAIR_ALLOW_DATA_LOSS-lausekkeella, suoritetaan seuraavat toimet:

• DBCC CHECKDB käyttää sivuja, jotka on merkitty käyttökelvottomiksi I/O- tai tarkistussummavirheiden vuoksi, ikään kuin virheitä ei olisi tapahtunut. Näin toimimalla tietokannan tietojen palautusmahdollisuudet paranevat.
• DBCC CHECKDB yrittää palauttaa tietokannan käyttämällä tavanomaisia lokipohjaisia palautustekniikoita.
• Jos tietokannan palautus ei onnistu tapahtumalokin vioittumisen vuoksi, tapahtumaloki rakennetaan uudelleen. Transaktiolokin uudelleenrakentaminen voi johtaa transaktiokonsistenssin menetykseen.

Jos DBCC CHECKDB -komento onnistuu, tietokanta on fyysisesti johdonmukaisessa tilassa ja tietokannan tilaksi on asetettu ONLINE. Tietokannassa voi kuitenkin olla yksi tai useampi tapahtumakohtainen epäjohdonmukaisuus. Suosittelemme, että suoritat DBCC CHECKCONSTRAINTS -komennon liiketoimintalogiikan virheiden tunnistamiseksi ja varmuuskopioit välittömästi tietokannan.Jos DBCC CHECKDB -komennon suorittaminen epäonnistuu, tietokantaa ei voida korjata.

DBCC CHECKDB -komennon suorittaminen REPAIR_ALLOW_DATA_LOSS -vaihtoehdon kanssa replikoiduissa tietokannoissa

DBCC CHECKDB -komennon suorittaminen vaihtoehdon REPAIR_ALLOW_DATA_LOSS kanssa voi vaikuttaa käyttäjätietokantoihin (julkaisu – ja tilaustietokannat) ja replikaatiokäytössä olevaan jakelutietokantaan. Julkaisu- ja tilaustietokannat sisältävät julkaistuja tauluja ja replikoinnin metatietotauluja. Huomioi seuraavat mahdolliset ongelmat näissä tietokannoissa:

• Julkaistut taulut. CHECKDB-prosessin suorittamia toimia, joilla korjataan vioittuneita käyttäjätietoja, ei ehkä replikoida:
• Merge-replikointi käyttää triggereitä julkaistujen taulujen muutosten seuraamiseen. Jos CHECKDB-prosessi lisää, päivittää tai poistaa rivejä, laukaisimet eivät laukea, joten muutosta ei replikoida.
• Transaktioreplikointi käyttää tapahtumalokia julkaistujen taulujen muutosten seuraamiseen. Lokinlukuagentti siirtää sitten nämä muutokset jakelutietokantaan. Joitakin DBCC-korjauksia, vaikka ne kirjataan lokiin, Log Reader Agent ei voi replikoida. Jos esimerkiksi CHECKDB-prosessi poistaa tietosivun, Lokinlukuagentti ei käännä tätä DELETE-lausekkeeksi, joten muutosta ei replikoida.
• Replikoinnin metatietotaulukot. CHECKDB-prosessin suorittamat toimet korruptoituneiden replikoinnin metatietotaulujen korjaamiseksi edellyttävät replikoinnin poistamista ja uudelleenmäärittämistä.

Jos joudut suorittamaan DBCC CHECKDB-komennon REPAIR_ALLOW_DATA_LOSS-vaihtoehdolla käyttäjätietokannassa tai jakelutietokannassa:

1. Käynnistä järjestelmä: Pysäytä toiminta tietokannassa ja kaikissa muissa replikaatiotopologian tietokannoissa ja yritä sitten synkronoida kaikki solmut. Lisätietoja on kohdassa Replikointitopologian hiljentäminen (Replikointi Transact-SQL-ohjelmointi).
2. Suorita DBCC CHECKDB.
3. Jos DBCC CHECKDB -raportti sisältää korjauksia mille tahansa jakelutietokannassa olevalle taululle tai jollekin käyttäjätietokannassa olevalle replikoinnin metatietotaululle, poista replikointi ja määritä se uudelleen. Lisätietoja on kohdassa Julkaisun ja jakelun poistaminen käytöstä.
4. Jos DBCC CHECKDB -raportti sisältää korjauksia mille tahansa replikoidulle taululle, suorita tietojen validointi sen määrittämiseksi, onko julkaisu- ja tilaustietokantojen tietojen välillä eroja.

Tulosjoukot

DBCC CHECKDB palauttaa seuraavan tulosjoukon. Arvot saattavat vaihdella, paitsi jos ESTIMATEONLY-, PHYSICAL_ONLY- tai NO_INFOMSGS-asetukset on määritetty:

 DBCC results for 'model'. Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13. Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5. Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3. Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0. DBCC results for 'sys.sysrowsetcolumns'. There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'. DBCC results for 'sys.sysrowsets'. There are 97 rows in 1 pages for object 'sys.sysrowsets'. DBCC results for 'sysallocunits'. There are 195 rows in 3 pages for object 'sysallocunits'. There are 0 rows in 0 pages for object "sys.sysasymkeys". DBCC results for 'sys.syssqlguides'. There are 0 rows in 0 pages for object "sys.syssqlguides". DBCC results for 'sys.queue_messages_1977058079'. There are 0 rows in 0 pages for object "sys.queue_messages_1977058079". DBCC results for 'sys.queue_messages_2009058193'. There are 0 rows in 0 pages for object "sys.queue_messages_2009058193". DBCC results for 'sys.queue_messages_2041058307'. There are 0 rows in 0 pages for object "sys.queue_messages_2041058307". CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. 

DBCC CHECKDB palauttaa seuraavan tulosjoukon (viestin), kun NO_INFOMSGS on määritetty:

 The command(s) completed successfully.

DBCC CHECKDB palauttaa seuraavan tulosjoukon, kun PHYSICAL_ONLY on määritetty:

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

DBCC CHECKDB palauttaa seuraavan tulosjoukon, kun ESTIMATEONLY on määritetty.

 Estimated TEMPDB space needed for CHECKALLOC (KB) ------------------------------------------------- 13 (1 row(s) affected) Estimated TEMPDB space needed for CHECKTABLES (KB) -------------------------------------------------- 57 (1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Oikeudet

Edellyttää jäsenyyttä kiinteässä palvelinroolissa sysadmin tai kiinteässä tietokantaroolissa db_owner.

Esimerkkejä

A. Sekä nykyisen että toisen tietokannan tarkistaminen

Seuraavassa esimerkissä suoritetaan DBCC CHECKDB nykyisen tietokannan ja AdventureWorks2012-tietokannan tarkistaminen.

-- Check the current database. DBCC CHECKDB; GO -- Check the AdventureWorks2012 database without nonclustered indexes. DBCC CHECKDB (AdventureWorks2012, NOINDEX); GO 

B. Nykyisen tietokannan tarkistaminen ja tiedotusviestien tukahduttaminen

Seuraavassa esimerkissä tarkistetaan nykyinen tietokanta ja tukahdutetaan kaikki tiedotusviestit.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Katso myös

DBCC (Transact-SQL)
Katso tietokannan tilannekuvan harvennetun tiedoston koon katsominen (Transact-SQL)
sp_helpdb (Transact-SQL)
Järjestelmätaulukot (Transact-SQL)

.