By: Brady Upton | Päivitetty: Upton Upton: 2016-07-26 | Comments (2) | Related: 2016-07-26 | Comments (2) | Related: 2016-07-26 | Comments (2) | Related: > Lisää > tietokantakonsolin komentoja DBCC:t

Ongelma

SQL Serverin tietokannan korruptoituminen voi olla ongelma ja aiheuttaa vakavia vahinkoja tietokannalle. Jos olet kokenut DBA, sinulla on luultavasti suojatoimia tämän havaitsemiseksi, mutta vuosien varrella olen nähnyt satoja SQL-palvelimia, joilla ei ole minkäänlaisia havaitsemismenetelmiä, ja tämä on ongelma. On olemassa muutamia tapoja havaita tietokannan vioittuminen, mutta tässä vinkissä keskitytään enemmän DBCC CHECKDB:hen.

Ratkaisu

Olet ehkä kuullut tai et ole kuullutDBCC (tietokantakonsolin komennot) -lausunnoista. Näitä lausekkeita käytetään eri toimintojen suorittamiseen tietokannassasi, ja ne voidaan jakaa neljään luokkaan: Ylläpito, Sekalaiset, Informatiiviset ja Validointi. Käytän joitakin DBCC-lauseita päivittäin, mutta en mitään enempää kuin DBCC CHECKDB:tä.

Mikä on SQL Serverin DBCC CHECKDB

DBCC CHECKDB, joka on peräisinMicrosoftin MSDN-kirjastosta, tarkastaa määritetyn tietokannan kaikkien objektien loogisen ja fyysisen eheyden suorittamalla seuraavat toiminnot:

  • Suorittaa tietokannassa DBCC CHECKALLOC:n – Tarkistaa määritetyn tietokannan levytilanjakorakenteiden johdonmukaisuuden.
  • Johtaa DBCC CHECKTABLE jokaiselle tietokannan taululle ja näkymälle – Tarkistaa kaikkien taulun tai indeksoidun näkymän muodostavien sivujen ja rakenteiden eheyden.
  • Suorittaa DBCC CHECKCATALOG tietokannassa – Tarkistaa luettelon johdonmukaisuuden tietokannassa.
  • Valvioi tietokannan jokaisen indeksoidun näkymän sisällön.
  • Valvioi linkkitason johdonmukaisuuden taulukon metatietojen ja tiedostojärjestelmänhakemistojen ja tiedostojen välillä, kun tiedostojärjestelmään tallennetaan varbinary(max)-tietoja FILESTREAMin avulla.
  • Validoi Service Brokerin tiedot tietokannassa

Jos olet joskus suorittanut DBCC CHECKDB:n, tiedät, että se vie jonkin verran aikaa suurissa tietokannoissa.Nyt kun tunnet kaikki suoritettavat vaiheet, ymmärrät, miksi sen suorittaminen vie aikaa.

Miten SQL Serverin DBCC CHECKDB:n suorittaminen voi auttaa minua?

Tiedon korruptoituneisuus on pahasta. Se voi aiheuttaa tietokannassa kaikenlaisia ongelmia, joihin voi kuulua virheellisiä tietotuloksia, epäonnistuneita SQL-lauseita ja joissain tapauksissavoi kaataa koko SQL-instanssin. DBCC CHECKDB varoittaa korruptiosta, jotta voit korjata sen ennen kuin se (toivottavasti) menee liian pahaksi.

Miten käytän SQL Serverin DBCC CHECKDB:tä?

DBCC CHECKDB on melko yksinkertainen. Lausekkeen kanssa voi käyttää muutamia vaihtoehtoja, ja käymme läpi joitakin niistä seuraavassa kappaleessa, mutta perussyntaksi näyttää tältä:

DBCC CHECKDB ('DatabaseName')

Aika yksinkertainen.

Automate SQL Server DBCC CHECKDB

Ei ole selvää, että haluat kirjautua sisään joka aamu ja suorittaa tämän lausekkeen jokaiselle tietokannalle, joten voit automatisoida tämän prosessin muutamalla eri menetelmällä:

  • SQL Serverin ylläpitosuunnitelmat -Huoltosuunnitelmat ovat osa SQL Serveriä suoraan laatikosta (ellet käytä ExpressEditionia). En suurimmaksi osaksi pidä ylläpitosuunnitelmien käyttämisestä, mutta tämäntyyppiseen tehtävään niiden käyttäminen ei haittaa. Ylläpitosuunnitelman työkalupakissa sinun on käytettävä Check Database Integrity -tehtävää. Ainoa konfiguroitavissa oleva vaihtoehto on sisällyttää indeksit, joten se ei ole kovin käyttäjäystävällinen, mutta joissakin tapauksissa tarvitset vain sen. Puhumme taas muista vaihtoehdoista seuraavassa osassa.
  • Mukautetut komentosarjat – Käytän yleensä mukautettuja komentosarjoja, jotka tarjoavat parhaan joustavuuden haluamiesi vaihtoehtojen lisäämisessä. Minun go-skriptini ovat valmiiksi luotuja ja vapaasti käytettävissäOla Hallengreniltä. Hän on tehnyt hienoa työtä luodessaan näitä ja jakaessaan niitä maailmalle. KiitosOla!
    • Katsokaa skriptit MSSQLTipsistä.com:
    • Ylläpidon suorittaminen SQL Server -tietokantojen kanssa Full Recovery -tilassa
    • SQL Server -tietokantojen ylläpitosuunnitelmat ja varmuuskopiotiedostojen hallinta
    • SQL Server -ylläpidon suorittaminen ilman ylläpitoikkunaa

SQL Server DBCC CHECKDB -vaihtoehtoja

Es on olemassa muutama vaihtoehto, joita voi käyttää DBCC CHECKDB:n kanssa, ja käyn läpi muutaman niistäsuosituimpia niistä tässä:

  • NOINDEX – Määrittää, että käyttäjätaulujen ei-klusteroitujen indeksien intensiivisiä tarkistuksia ei suoriteta. Tämä vähentää ylikierroksen suoritusaikaa. NOINDEX ei vaikuta järjestelmätaulukoihin, koska eheystarkastukset suoritetaan aina järjestelmätaulukoiden indekseille.
  • NO_INFOMSGS – Tukahduttaa kaikki informaatioviestit.
  • PHYSICAL_ONLY – Rajoittaa tarkastuksen koskemaan vain sivun ja tietueiden otsikoiden fyysisen rakenteen eheyttä ja tietokannan allokaatiokonsistenssiä. Tämä tarkistus on suunniteltu tarjoamaan pienen yleiskustannuksen tietokannan fyysisen johdonmukaisuuden tarkistus, mutta se voi myös havaita repeytyneet sivut, tarkistussummavirheet ja yleiset laitteistoviat, jotka voivat vaarantaa käyttäjän tiedot.
  • TABLOCK – Aiheuttaa DBCC CHECKDB:n hankkimaan lukituksia sen sijaan, että se käyttäisi tietokannan sisäistä tilannekuvaa. Tämä sisältää tietokannan lyhytaikaisen yksinoikeuslukon (X-lukko). TABLOCK saa DBCC CHECKDB:n toimimaan nopeammin tietokannassa, jossa on suuri kuormitus, mutta vähentää tietokannan käytettävissä olevaa samanaikaisuutta DBCC CHECKDB:n ollessa käynnissä.
  • DATA_PURITY – Saattaa DBCC CHECKDB:n tarkistamaan tietokannasta sarakkeiden arvot, jotka eivät ole kelvollisia tai jotka ovat alueen ulkopuolella. DBCC CHECKDBhavaitsee esimerkiksi sarakkeet, joiden päivämäärän ja kellonajan arvot ovat suurempia tai pienempiä kuin datetime-tietotyypin hyväksyttävä alue; tai desimaaliset tai likimääräiset numeerisettietotyypin sarakkeet, joiden asteikko- tai tarkkuusarvot eivät ole kelvollisia.

Käymme läpi joitain KORJAUSvaihtoehtoja eri osiossa alempana.

Kuinka usein SQL Serverin korruptoituneisuus on tarkistettava?

Jokainen minuutti joka päivä. Kunhan vitsailin vain.

Jos sinulla on päivittäinen ylläpitoikkuna, olisi kiva tarkistaa tietojen korruptoituminenpäivittäin. Mitä nopeammin sen saa kiinni, sitä vähemmän haittaa siitä voi olla. Olen huomannut, että monet ajavat tämän viikonloppuisin varsinkin isommissa tietokannoissa. Tässä ei ole mitään oikeaa tai väärää, kunhan varmistat, että se ajoitetaan säännöllisesti.

Pitäisikö minun ajaa DBCC CHECKDB tuotantoympäristössäni?

Ei, no kyllä. Tavallaan.

Tietojen korruptoitumisen tarkistamiseksi DBCC CHECKDB:n suorittaminen testiympäristössäsi ei auta, paitsi jos palautat kopion tuotantoympäristöstäsi testiin ja suoritat sen sitten. BRILLIANT!

Voi olla, että kyseenalaistat joidenkin HA-vaihtoehtojen soveltuvuuden, kuten AlwaysOn, LogShipping jne. Ei, sinun on tarkistettava tuotantoympäristösi *elävä*.

Nyt kun DBCC CHECKDB on konfiguroitu ja käynnissä, mitä etsin?

Onnittelut! DBCC CHECKDB on automatisoitu ja käynnissä, mutta mitä nyt? Jos sinulla onSQL ServerAgent Job -asetus, varmista, että olet määrittänytDatabase Mailin, operaattorin ja ilmoituksen tehtävään. Jos työ onnistuu, jatka kaunista päivääsi. Jos työ epäonnistuu, meillä on hieman työtä tehtävänä.

Saatat nähdä tällaisen virheen:

The In-row data USED page count for object ”tablename”, index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (type In-row data) is incorrect.Run DBCC UPDATEUSAGE. (Virhe 2508) In-row data RSVD pagecount for object ”tablename”, index ID 2, par… Vaihe epäonnistui.

tai tämä:

Objektin ID 2088535921, indeksin ID 0, osion ID 72345201021503994, allokointiyksikönID 72345201051571606 (tyyppi In-row data): Sivua (1:94299) ei voitu käsitellä.Katso lisätietoja muista virheistä. Msg 8939, Level 16, State 98, Line 1 Taulukkovirhe: Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data), page (1:94299). Testi (IS_OFF (BUF_IOERR,pBUF->bstat)) epäonnistui. CHECKDB löysi 0 allokaatiovirhettä ja 2 konsistenssivirhettä taulusta ’tablename’ (objektin ID 2088535921). CHECKDB löysi 0 allokaatiovirhettä ja 2 konsistenssivirhettä tietokannassa ’tablename’. repair_allow_data_losson vähimmäiskorjaustaso DBCC CHECKDB:n (tietokanta) löytämille virheille.

Ensiksi, älä hätäänny. Toiseksi, tarkista varmuuskopiot. DBCC CHECKDB:n virheet kertovat yleensä, mitä on tehtävä.

Ensimmäisen virheen kohdalla DBCC UPDATEUSAGE korjaa sivu- ja rivimäärän epätarkkuudet luettelonäkymissä. Melko harmitonta.

Kakkosvirhe ilmoittaa tietojen korruptoitumisesta. Virheessä mainitaan repair_allow_data_lossin käyttäminen vähimmäiskorjaustasona. Tämä tarkoittaa, että voit suorittaa lausekkeen tällä argumentilla, mutta saatat menettää tietoja. Tämän vuoksi suosittelen aina palauttamista varmuuskopioon, jos voit. Sinun on varmistettava, ettei varmuuskopio sisällä vioittuneita tietoja, ja haluat varmistaa, ettei tietoja menetetä.

SQL Server -tietokannan korjaaminen

Jos sinulla ei ole varmuuskopiota, saatamme joutua käyttämään DBCC CHECKDB:tä korjausvaihtoehdon kanssa.Tässä ovat käytettävissä olevat korjausvaihtoehdot. Nämä voivat toimia tai olla toimimattaja niitä on käytettävä viimeisenä keinona:

  • REPAIR_ALLOW_DATA_LOSS – Yrittää korjata kaikki ilmoitetut virheet.Nämä korjaukset voivat aiheuttaa jonkin verran tietojen menetystä.
  • REPAIR_REBUILD – Suorittaa korjaukset, joissa ei ole mahdollisuutta tietojen menetykseen. Tämä voi sisältää nopeita korjauksia, kuten puuttuvien rivien korjaaminen ei-klusteroitujen indeksien osalta, ja aikaa vievämpiä korjauksia, kuten indeksin uudelleenrakentaminen.

Kuten edellä sanoin, on erittäin tärkeää, että sinulla on ajan tasalla olevat varmuuskopiot, jotta voit toipua korruptiosta. Korruptio ei välitä siitä, kuinka paljon dataa sinulla on, mitä SQL-versiota käytät tai kuinka hieno datakeskuksesi on.

Minusta tuntuu aika hyvältä, mutta mitä muuta voin käyttää SQL-instanssien suojaamiseen?

DBCC CHECKDB pitäisi ajaa jokaisessa SQL-instanssissasi, mutta on pari muutakin tapaa, jotka voivat auttaa havaitsemaan/estämään datan korruptoitumisen.

  • SQL Server Agentin hälytykset – Brian Kelley kirjoitti mukavan vinkin tästä aiheesta täällä.
  • Sivun tarkistus – Varmista, että tietokantasi käyttävätCHECKSUM-sivun tarkistusta. Jos käytät vielä SQL 2005:tä tai sitä nuorempaa versiota, tämä ei ole käytettävissä, mutta päivityksen jälkeen varmista, että muutat tämän asetuksen. Näet sivujen tarkistusasetukset seuraavalla lausekkeella:
select name, page_verify_option_desc from sys.databases
Seuraavat vaiheet
  • Tarkista, että tutustutMSDN-kirjastoon, josta saat syvällisempiä yksityiskohtia DBCC CHECKDB:stä
  • MSSQLTips.com-sivustolla on hieno kokoelma vinkkejä tietokantojen johdonmukaisuuden tarkistuksista, jotka voivat olla myös hyödyllisiä.

Viimeisin päivitetty:

Kirjoittajasta
Brady Upton on tietokannan ylläpitäjä ja SharePointin supertähti Nashvillessä, TN.
Katso kaikki vinkkini
Aiheeseen liittyvät resurssit

  • Muut SQL Server DBA -vinkit…

By: adminPosted on

Vastaa

Sähköpostiosoitettasi ei julkaista.