Optimizarea dbcc checkdb

Datoriile tale, cum ar fi DBA, includ probabil optimizarea performanței, recuperarea, stabilirea drepturilor de acces și așa mai departe. Dar mulți au tendința de a uita de o operațiune atât de importantă ca DBMS CHECKDB. Puteți rezolva această problemă pur și simplu prin crearea unui plan de întreținere pentru sarcina de verificare a integrității bazelor de date, dar acesta este doar un checkdbox.







Optimizarea dbcc checkdb

După cum puteți vedea, greu putem controla ceva aici, deși există multe chei interesante pentru această operațiune. Cred că ar trebui să intrați mai mult în DBCC CHECKDB și să vă creați propria sarcină potrivită pentru dvs. Principalul avantaj al propriei sarcini va fi reducerea timpului de lucru și, ca o consecință, reducerea resurselor necesare pentru această operațiune. Pot exista și avantaje precum universalitatea, gestionabilitatea, gestionarea erorilor și așa mai departe.

Reduceți producția și colectați toate erorile:

Nu contează unde executați CHECKDB, întotdeauna începeți cu opțiunea WITH NO_INFOMSGS. Această opțiune simplă suprimă toate mesajele informaționale pe care pur și simplu spune câte rânduri în fiecare tabel, în cazul în care aveți nevoie de aceste informații, puteți obține de la DMV, este comanda CHECKDB.

Utilizați numai verificarea fizică a datelor într-un mediu productiv:

În cele mai multe cazuri, CHECKDB petrece cea mai mare parte a timpului verificând logic datele. Dacă puteți efectua acest test pe o copie fiabilă a datelor, atunci vă puteți concentra doar asupra structurii fizice a sistemului dvs. productiv. Sub o copie fiabilă a datelor, vreau să spun NUMAI să restaurez baza de date din copia de rezervă pe un alt server.

Astfel de metode precum:

  1. AlwaysOn Group de disponibilitate
  2. Snapshot pe oglindirea bazei de date
  3. Log Shipping
  4. Și așa mai departe.

Nu sunt o copie fiabilă a datelor și o verificare logică a acestor tehnologii nu va da un rezultat fiabil cu privire la mediul productiv. Numai exact aceeași copie a bazei de date poate fi fiabilă.

Experimente cu steaguri de urmărire 2549, 2562 și 2566:

Am constatat că stecile de urmărire 2549 și 2562 pot îmbunătăți performanța CHECKDB. Puteți găsi descrierea acestor steaguri în KB # 2634571. dar în general:

Trace pavilion 2549 (optimizează procesul de verificare a calculului pe care fiecare fișier de date de bază de date este pe cont propriu unitate. Semnalizatorul poate fi utilizat atunci când baza de date are un fișier de date sau un fișier de date se află pe unitatea, în caz contrar se poate degrada performanța CHECKDB)







Dacă decideți să utilizați aceste steaguri, vă recomand să le activați cu DBCC TRACEON și nu prin opțiunile de pornire SQL Server. Acest lucru vă va oferi opțiunea de a dezactiva stegulețele fără a reporni.

Reduceți sarcina pe subsistemul disc (optimizarea tempdb):

DBCC CHECKDB poate încărca greu tempdb, încerca să aloce suficiente resurse pentru această bază de date (test).

Reduceți sarcina pe subsistemul disc (instantaneu):

Lansarea DBCC CHECKDB, versiuni moderne ale SQL Server creează o imagine ascunsă a bazei de date pe aceeași unitate (sau pe același disc dacă utilizați mai multe fișiere tempdb). Nu poți controla acest mecanism, dar dacă doriți să specificați exact în cazul în care aveți nevoie pentru a crea un instantaneu, puteți face instantaneu pe orice unitate (disponibilă numai în Enterprise Edition) și a alerga DBCC CHECKDB pe instantaneu. Cel mai bine este să utilizați această metodă în timpul perioadei de activitate minimă la actualizarea înregistrărilor bazei dvs. de date.

Puteți accelera DBCC CHECKDB executându-l în modul offline (cu încuietori) folosind opțiunea WITH TABLOCK. Eu strict nu recomand să folosiți acest lucru, deoarece acest lucru va înrăutăți în mod semnificativ disponibilitatea bazei de date.

Reducerea încărcării procesorului:

DBCC CHECKDB rulează în mod paralel în mod implicit, dar numai dacă aveți o ediție Enterprise Edition. Dacă nu aveți suficiente resurse CPU, puteți reduce concurența în mai multe moduri:

Din păcate, Microsoft nu intenționează să pună în aplicare utilizarea lui MAXDOP pentru CHECKDB, deși au fost în mod repetat întrebări despre acest lucru.

Rezultatele mele:

Optimizarea dbcc checkdb

Rezultate CHECKDB împotriva bazei de date de 7 GB

Apoi, am mărit mărimea bazei de date la 70 GB și am testat din nou:

Optimizarea dbcc checkdb

Rezultatele CHECKDB față de baza de date de 70 GB

Principalele gânduri după teste:

  1. Când am rulat DBCC CKECKDB cu un control logic pe serverul de luptă:
    • În bazele de date mici, opțiunea NO_INFOMSGS poate reduce semnificativ timpul de execuție atunci când este pornit în SSMS. În baze de date mari, efectul este redus.
    • Ambele steaguri au avut un efect semnificativ asupra performanței DBCC CHECKDB (40% -60% atunci când sunt utilizate împreună)
  2. Când am rulat DBCC CKECKDB cu un control logic pe secundar:
    • Am redus timpul de execuție cu 70-80% în sistemul de luptă.

Aș dori să demonstrez sarcina pe procesor în timpul DBCC CHECKDB:

Optimizarea dbcc checkdb

Impactul procesorului în timpul modului CHECKDB - eșantion

Optimizarea dbcc checkdb

Impactul procesorului în timpul CHECKDB - modul istoric

În bazele de date de mari dimensiuni, rezultatele pot varia, deci trebuie să efectuați cu siguranță propriile teste.

concluzie:

DBCC CHECKDB este o sarcină DBA foarte importantă și adesea subestimată. Nu faceți greșeli ale altor DBA-uri.







Articole similare

Trimiteți-le prietenilor: