DBCC CHECKDB Not Run Recently

Când SQL Server scrie date pe unitățile dvs. de disc, acesta presupune că totul este în regulă până când trebuie să citească din nou datele.

Din păcate, în cazul în care stocarea este coruptă, aceasta nu este atât de amabilă încât să alerteze SQL Server. Și, uneori, se știe că SQL Server s-a corupt chiar el însuși.

Trebuie să verificăm periodic pentru a ne asigura că datele de pe disc încă mai au sens, și aici intervine DBCC CHECKDB. Acesta verifică atât erorile de alocare, cât și erorile de consistență. În plus, dacă există probleme, mesajele de eroare vor reveni cu informații referitoare la locul unde există erorile, la gravitatea erorii, precum și la opțiunea de reparare sugerată.

Este esențial să rulăm CHECKDB în mod regulat pentru a găsi erori dacă acestea există, deoarece dacă există corupție, trebuie să o reparăm înainte ca ultimele noastre copii de rezervă bune să dispară.

Pentru a găsi problema, verificăm fiecare bază de date pentru a ne asigura că DBCC CHECKDB a finalizat cu succes o verificare în ultimele două săptămâni.

Nu credeți?

„Dar eu execut CHECKDB tot timpul”, ați putea spune – ei bine, haideți să aflăm:

Transact-SQL

1	DBCC DBINFO(‘StackOverflow’) WITH TABLERESULTS

Asta este. Dar rezultatul este un coșmar. Sunt aproximativ 80 de rânduri de chestii de care probabil nu vă va interesa niciodată. În jurul liniei 50 este ceea ce căutați.

Bună, sunt un nonsens.

Și asta este probabil ceea ce veți vedea! O dată de 1900-01-01-01 etc. Asta înseamnă niciodată. Dacă rulați DBCC CHECKDB pe baza de date, poate așa:

Transact-SQL

1	DBCC CHECKDB(‘StackOverflow’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Și apoi executați din nou comanda DBCC DBINFO, data noastră este acum actualizată la curent:

Uită-te cât de mult ne distrăm

Dacă data nu se actualizează, asta înseamnă unul din două lucruri: SQL Server nu poate scrie în baza de date (ca și cum ar fi doar pentru citire), sau găsește erori (hoowee, nu e bine.)

Pentru a rezolva problema

Decideți dacă doriți să folosiți planurile de întreținere încorporate sau un instrument gratuit, cum ar fi scripturile CHECKDB gratuite ale lui Ola Hallengren. Câteva considerații:

• Planurile de întreținere au o interfață grafică, în cazul în care nu cunoașteți T-SQL.
• Scripturile gratuite ale lui Ola Hallengren se ocupă de opțiunile de reglaj fin, cum ar fi rularea automată a verificărilor data_purity (ceea ce este un lucru bun).

Cum să configurați întreținerea regulată pentru a verifica dacă există corupție

Opțiunea 1: Utilizați un plan de întreținere pentru a rula DBCC CHECKDB

Dacă utilizați planuri de întreținere, puteți edita planurile de întreținere în SQL Server Management Studio sub Management, Maintenance Plans. Serverul dumneavoastră poate avea mai multe planuri de întreținere care execută CHECKDB pentru diferite tipuri de baze de date, cum ar fi unul pentru bazele de date de sistem și unul pentru bazele de date de utilizator.

Extindeți nodul Management în SSMS, faceți clic dreapta pe Maintenance Plans și selectați New Plan.

Din fereastra Toolbox, care uneori se ascunde în stânga, trageți Check Database Integrity Task în fila Maintenance Plan.

Când faceți dublu clic pe caseta Check Database Integrity Task din fila Maintenance Plan, veți putea alege ce baze de date doriți să fie verificate în timpul procesului.

De aici, tot ce mai rămâne este programarea, care este la fel ca programarea unui Agent Job.

După ce salvați și închideți planul de întreținere, asigurați-vă că găsiți jobul aferent în SQL Server Agent și setați proprietățile Notification pentru a anunța un operator dacă acesta eșuează.

Opțiunea 2: Configurați joburile SQL Agent pentru a rula DBCC CHECKDB folosind scripturile gratuite ale lui Ola Hallengren

Și implementați verificări de integritate pentru prima dată, luați în considerare utilizarea scripturilor gratuite de întreținere ale lui Ola Hallengren. Acestea nu sunt la fel de ușoare ca planurile de întreținere, dar sunt mult mai flexibile. Ele includ, de asemenea, posibilitatea de a împărți operațiunile DBCC în bucăți mai mici pentru bazele de date mari. La bazele de date foarte mari, CHECKDB poate necesita o cantitate semnificativă de timp și resurse – opțiunea WITH PHYSICAL_ONLY este mai rapidă, dar omite verificările logice.

După ce posturile de lucru ale agentului sunt instalate, le puteți programa să ruleze la fel de simplu ca și planurile de întreținere, sau le puteți regla fin cu ajutorul opțiunilor suplimentare documentate aici.