avem un pic de istorie de rezervă aici.

avem un pic de istorie de rezervă aici.

SQL Server urmărește istoricul fiecărei copii de rezervă. Stochează aceste date în baza de date MSDB. Aceasta este o bază de date de sistem și, în mod implicit, bazele noastre de date de sistem sunt stocate pe unitatea C, dacă nu se specifică altfel în timpul instalării.

acest lucru prezintă pericol în câteva moduri diferite:

unitatea C S-ar putea umple, provocând msdb scrie să eșueze. Unitatea de sistem se umple mai des decât ați putea crede – cauzată de utilizatorii neglijenți care descarcă fișiere uriașe pe desktopul lor (situat pe unitatea de sistem) sau de actualizările Windows care descarcă multe fișiere într-un folder temporar de pe unitatea de sistem.

MSDB ar putea crește pentru a umple unitatea C, cauzând Windows să eșueze. În cazurile în care facem copii de rezervă foarte frecvente ale jurnalelor de tranzacții ale unui număr mare de baze de date și nu curățăm niciodată MSDB, această bază de date poate deveni suficient de mare pentru a amenința unitățile c mici. Când unitatea C se umple, Windows eșuează greu.

unitatea de sistem este adesea lentă. În versiunile vechi de SQL Server, bazele de date de sistem nu au fost indexate bine. Combinați acest lucru cu unitățile locale lente și avem o rețetă pentru accesul lent la MSDB. Într-un caz, în timpul nostru de noapte de backup pentru windows, 2/3 din timp a fost petrecut doar actualizarea MSDB!

instrumentele de monitorizare pot interoga MSDB ineficient. Am văzut cazuri în care instrumentele de monitorizare a serverului terță parte au verificat în mod constant MSDB pentru a se asigura că toate bazele de date au fost salvate, dar interogările lor nu au folosit indexuri. Aceste interogări pot fi cel mai lent lucru de pe server.

această parte a scriptului nostru SQL Server sp_Blitz verifică dacă există un istoric de backup MSDB mai vechi de 60 de zile. Acest lucru în sine nu este o problemă – poate doriți să păstrați perioade lungi de istorie de rezervă acolo doar pentru a face raportarea performanței tranzitată – dar luați în considerare mutarea acestor date în Excel sau instrumentul dvs. preferat de raportare, mai degrabă decât să atingeți MSDB de fiecare dată.

reveniți la sp_Blitz sau puneți-ne întrebări

cum să curățați istoricul de rezervă MSDB supraîncărcat

luați în considerare curățarea istoricului de rezervă MSDB al datelor mai vechi de 60 de zile. Puteți face acest lucru în câteva moduri diferite:

  • puteți crea un plan de întreținere care execută în mod regulat activitatea de curățare a istoricului.
  • puteți crea un simplu SQL Server Agent de locuri de muncă care se execută sp_delete_backuphistory în mod regulat (puteți, de asemenea, să-l rulați sp_purge_jobhistory dacă doriți să se potrivească funcționalitatea planului de întreținere).

extindeți la nodul planului de întreținere din SSMS, faceți clic dreapta și alegeți ” Plan de întreținere nou…”

2015-04-10_14-20-46

alegeți sarcina de curățare a întreținerii din fereastra Toolbox (rețineți că uneori această fereastră se ascunde la stânga sub Object Explorer în SSMS:

2015-04-10_14-21-26

pentru a termina, faceți dublu clic pe sarcină, alegeți tipul de curățare pe care doriți să îl faceți și cantitatea de date pe care doriți să o păstrați. Uneori voi crea două sarcini, deoarece îmi pasă mai puțin de istoricul joburilor agentului și de istoricul planului de întreținere decât de backup-urile și, de obicei, vreau ca istoricul backup-urilor să se potrivească cu politica mea de păstrare a datelor.

2015-04-10_14-22-03

în orice caz, dacă serverul dvs. are o cantitate mare de istoric, acest pas va dura mult timp pentru a rula prima dată. După cum a menționat Brent în articolul msdb bottleneck, este posibil să trebuiască să recurgeți la măsuri extreme, cum ar fi schimbarea cheilor străine ale bazei de date a sistemului, doar pentru a obține ștergerea.

Lasă un răspuns

Adresa ta de email nu va fi publicată.