SQL Server DBCC CHECKDB Prezentare generală

De: Brady Upton | Actualizat: 2016-07-26 | Comentarii (2) | Related: Mai multe > Comenzi ale consolei de baze de date DBCCs

Problemă

Corupția bazei de date SQL Server poate fi o problemă și poate provoca daune serioase unei baze de date. Dacă sunteți un DBA cu experiență, atunci probabil că aveți măsuri de protecție pentru a detecta acest lucru, dar de-a lungul anilor am văzut sute de servere SQL Server fără nici o metodă de detectare și aceasta este o problemă. Există câteva modalități de a detecta corupția bazei de date, dar acest sfat se va concentra mai mult pe DBCC CHECKDB.

Soluție

Poate că ați auzit sau nu de declarațiileDBCC (comenzi de consolă pentru baze de date). Aceste instrucțiuni sunt folosite pentru a efectuadiferite operații în baza de date și pot fi împărțite în patru categorii:Întreținere, Diverse, Informaționale și Validare. Eu folosesc zilnic unele dintre declarațiile DBCC, dar niciuna mai mult decât DBCC CHECKDB.

Ce este SQL Server DBCC CHECKDB

DBCC CHECKDB, dinMicrosoft MSDN Library, verifică integritatea logică și fizică a tuturor obiectelor din baza de date specificată prin efectuarea următoarelor operații:

• Execută DBCC CHECKALLOC pe baza de date – Verifică consistența structurilor de alocare a spațiului pe disc pentru o bază de date specificată.
• Execută DBCC CHECKTABLE pe fiecare tabel și vizualizare din baza de date – Verifică integritatea tuturor paginilor și structurilor care alcătuiesc tabelul sau vizualizarea indexată.
• Execută DBCC CHECKCATALOG pe baza de date – Verifică consistența catalogului în cadrul bazei de date.
• Validează conținutul fiecărei vizualizări indexate din baza de date.
• Validează consistența la nivel de legătură între metadatele tabelelor și directoarele și fișierele din sistemul de fișiere atunci când se stochează date varbinare(max) în sistemul de fișiere folosindFILESTREAM.
• Validează datele Service Broker din baza de date

Dacă ați rulat vreodată DBCC CHECKDB știți că durează ceva timp pentru bazele de date mari.Acum că știți toți pașii care sunt executați, puteți vedea de ce durează să se finalizeze.

Cum mă poate ajuta SQL Server DBCC CHECKDB?

Corupția datelor este rea. Poate cauza tot felul de probleme în cadrul bazei de datecare pot include rezultate incorecte ale datelor, instrucțiuni SQL eșuate și, în unele cazuri, poate duce la căderea întregii instanțe SQL. DBCC CHECKDB vă avertizează în legătură cu corupția, astfel încât să o puteți remedia înainte ca (sperăm) să devină prea gravă.

Cum se utilizează SQL Server DBCC CHECKDB?

DBCC CHECKDB este destul de simplu. Există câteva opțiuni pe care le puteți folosi cu această instrucțiune și vom trece în revistă unele dintre ele în secțiunea următoare, dar sintaxa de bază arată astfel:

DBCC CHECKDB ('DatabaseName') 

Prea simplu.

Automate SQL Server DBCC CHECKDB

Evident, nu doriți să vă conectați în fiecare dimineață și să rulați această instrucțiune pe fiecare bază de date, așa că puteți automatiza acest proces folosind câteva metode diferite:

• Planuri de întreținere SQL Server -Planurile de întreținere fac parte din SQL Server din fabrică (cu excepția cazului în care executați ExpressEdition). Nu-mi place să folosesc planurile de întreținere în cea mai mare parte, dar nu mă deranjează să le folosesc pentru acest tip de sarcină. În setul de instrumente Maintenance Plan (Plan de întreținere) va trebui să folosiți sarcina Check Database Integrity (Verificarea integrității bazei de date). Singura opțiune configurabilă este de a include indici, deci nu este foarte ușor de utilizat, dar în unele cazuri este tot ce aveți nevoie. Din nou, vom vorbi despre alte opțiuni în secțiunea următoare.

• Scripturi personalizate – Scripturile personalizate sunt de obicei cele pe care le folosescși oferă cea mai bună flexibilitate în ceea ce privește adăugarea opțiunilor pe care le doriți. Scripturile mele go-toscripte sunt deja create și pot fi folosite gratuit de laOla Hallengren. El a făcut o treabă minunată creându-le și împărtășindu-le lumii. MulțumescOla!
• Verificați scripturile pe MSSQLTips.com:
• Realizați mentenanța cu bazele de date SQL Server în modul Full Recovery
• SQL Server Database Maintenance Plans and Backup File Management
• Realizați mentenanța SQL Server fără fereastră de mentenanță

SQL Server DBCC CHECKDB Options

Există câteva opțiuni de utilizat cu DBCC CHECKDB și voi trece în revistă câteva dintre cele mai populare aici:

• NOINDEX – Specifică faptul că nu trebuie efectuate verificări intensive ale indexurilor neaglomerate pentru tabelele utilizatorilor. Acest lucru scade timpul de supraexecuție. NOINDEX nu afectează tabelele de sistem, deoarece verificările de integritate se efectuează întotdeauna asupra indexurilor tabelelor de sistem.
• NO_INFOMSGS – Suprimă toate mesajele de informare.
• PHYSICAL_ONLY – Limitează verificarea la integritatea structurii fizice a capetelor de pagină și de înregistrare și la consecvența de alocare a bazei de date. Această verificare este concepută pentru a oferi o mică verificare a consistenței fizice a bazei de date, dar poate detecta, de asemenea, paginile rupte, eșecurile sumelor de control și defecțiunile hardware obișnuite care pot compromite datele unui utilizator.
• TABLOCK – Determină DBCC CHECKDB să obțină încuietori în loc să folosească un instantaneu intern al bazei de date. Aceasta include o blocare exclusivă (X) pe termen scurt asupra bazei de date. TABLOCK va face ca DBCC CHECKDB să ruleze mai repede pe o bază de date supusă unei sarcini mari, dar scade concurența disponibilă pe baza de date în timp ceDBCC CHECKDB rulează.
• DATA_PURITY – Determină DBCC CHECKDB să verifice baza de datepentru valorile coloanelor care nu sunt valide sau sunt în afara intervalului. De exemplu, DBCC CHECKDBdetectează coloanele cu valori de dată și oră care sunt mai mari sau mai mici decât intervalul acceptabil pentru tipul de date datatime; sau coloanele de tip zecimal sau de date numerice aproximative cu valori de scală sau de precizie care nu sunt valide.

Vom trece în revistă unele dintre opțiunile REPAIR într-o altă secțiune de mai jos.

Cât de des ar trebui să verific dacă SQL Server este corupt?

În fiecare minut din fiecare zi. Glumeam și eu.

Dacă aveți o fereastră de întreținere zilnică, ar fi bine să verificați corupția datelor zilnic. Cu cât o puteți prinde mai repede, cu atât mai puțin rău poate face. Am observat că multă lume execută acest lucru în weekend, mai ales cu baze de date mai mari. Nu există nimic corect sau greșit în acest sens, doar asigurați-vă că o programați periodic.

Trebuie să rulați DBCC CHECKDB în mediul meu de producție?

Nu, ei bine, da. Un fel de.

Pentru a verifica dacă există corupție de date, nu are nici un rost să rulați DBCC CHECKDB în mediul de testare…DOAR dacă nu restaurați o copie a mediului de producție pentru a testa și apoi o rulați. BRILLIANT!

S-ar putea să vă întrebați dacă unele opțiuni HA sunt potrivite, cum ar fi AlwaysOn, LogShipping, etc.? Nu, trebuie să verificați mediul dvs. de producție *live*.

Acum că DBCC CHECKDB este configurat și rulează, ce trebuie să caut?

Felicitări! Aveți DBCC CHECKDB automatizat și în funcțiune, dar acum ce urmează? Dacă aveți configurat unSQL ServerAgent Job, atunci asigurați-vă că ați configuratDatabase Mail,un operator și o notificare pe job. Dacă treaba reușește, atunci continuați cu ziua voastră frumoasă. Dacă treaba eșuează, atunci avem ceva de lucru.

Puteți vedea o eroare de genul acesta:

sau aceasta:

În primul rând, nu intrați în panică. În al doilea rând, verificați copiile de rezervă. Erorile DBCC CHECKDB vă spun, de obicei, ce trebuie făcut.

Pentru prima eroare, un DBCC UPDATEUSAGE va corecta inexactitățile de numărare a paginilor și rândurilor în vizualizările de catalog. Destul de inofensiv.

Cea de-a doua eroare raportează corupția datelor. Eroarea menționează utilizarea repair_allow_data_loss ca nivel minim de reparare. Aceasta înseamnă că puteți rula instrucțiunea cu acest argument,dar este posibil să pierdeți date. Acesta este motivul pentru care recomand întotdeauna restaurarea pe o copie de rezervă, dacă se poate. Trebuie să vă asigurați că copia de rezervă nu conține date corupte și doriți să vă asigurați că nu există pierderi de date.

Cum se repară o bază de date SQL Server

Dacă nu aveți o copie de rezervă, este posibil să trebuiască să folosim DBCC CHECKDB cu o opțiune de reparare.Iată care sunt opțiunile de reparare care pot fi folosite. Acestea pot funcționa sau nu și trebuie folosite în ultimă instanță:

• REPAIR_ALLOW_DATA_LOSS – Încearcă să repare toate erorile raportate.Aceste reparații pot cauza unele pierderi de date.
• REPAIR_REBUILD – Efectuează reparații care nu au nici o posibilitatede pierdere de date. Acest lucru poate include reparații rapide, cum ar fi repararea rândurilor lipsăîn indici neaglomerate, și reparații care necesită mai mult timp, cum ar fi reconstrucțiaunui indice.

Cum am spus mai sus, este foarte important să aveți până la databackup-uri pentru a recupera din corupție. Corupției nu-i pasă cât de multe date aveți, ce versiune de SQL rulați sau cât de fantezist este centrul dumneavoastră de date.

Mă simt destul de bine în legătură cu acest lucru, dar ce altceva pot folosi pentru a-mi proteja instanțele SQL?

DBCC CHECKDB ar trebui să fie rulat pe fiecare instanță SQL pe care o aveți, dar există câtevaalte modalități care pot ajuta la detectarea/prevenirea corupției datelor.

• SQL Server Agent Alerts – Brian Kelley a scris un sfat frumos pe acest subiect aici.
• Page verification – Asigurați-vă că bazele de date folosesc verificarea paginilor CHECKSUM. Dacă încă rulați SQL 2005 sau o versiune inferioară, acest lucru nu este disponibil, dar după ce faceți upgrade asigurați-vă că modificați această setare. Pentru a vedea setările de verificare a paginilor folosiți următoarea instrucțiune:

select name, page_verify_option_desc from sys.databases 

Pasi următori

• Asigură-te că verifici BibliotecaMSDN pentru detalii mai amănunțite cu privire la DBCC CHECKDB
• MSSQLTips.com are o colecție frumoasă de sfaturi cu privire laDatabase Consistency Checks (Verificări de consistență a bazelor de date) care poate fi de asemenea utilă.

Ultima actualizare: 2016-07-26

Despre autor

Brady Upton este un administrator de baze de date și un superstar SharePoint în Nashville, TN.
Vezi toate sfaturile mele

Resurse conexe

• Mai multe sfaturi SQL Server DBA…

.