Vi har litt backup historie her.

Vi har litt backup historie her.

SQL Server sporer historikken til hver sikkerhetskopi. Den lagrer disse dataene i msdb-databasen. Det er en systemdatabase, og som standard lagres våre systemdatabaser på c-stasjonen, med mindre annet er angitt under installasjonen.

dette utgjør fare på noen forskjellige måter:

c-stasjonen kan fylle opp, noe SOM fører TIL AT msdb-skriver mislykkes. Systemstasjonen fylles opp oftere enn du kanskje tror-forårsaket av uforsiktige brukere som laster ned store filer til skrivebordet (plassert på systemstasjonen) eller Ved Windows-Oppdateringer som laster ned mange filer til en midlertidig mappe på systemstasjonen.

MSDB kan vokse til å fylle c-stasjonen, slik At Windows mislykkes. I tilfeller der vi gjør svært hyppige transaksjonslogg backup av et stort antall databaser, og vi aldri rense MSDB, denne databasen kan vokse til å bli stor nok til å true små c-stasjoner. Når c-stasjonen fylles, mislykkes Windows hardt.

systemstasjonen er ofte treg. I gamle versjoner AV SQL Server ble systemdatabasene ikke indeksert godt. Kombiner dette med treg lokale stasjoner, og vi har en oppskrift på treg msdb-tilgang. I ett tilfelle, under våre nattlige backup vinduer, 2/3 av tiden ble brukt bare oppdatere MSDB!

Overvåkingsverktøy kan spørre msdb ineffektivt. Vi har sett tilfeller der tredjeparts serverovervåkingsverktøy konstant sjekket MSDB for å sikre at alle databaser ble sikkerhetskopiert, men deres spørsmål brukte ikke indekser. Disse spørringene kan være den tregeste tingen på serveren.

denne delen av SQL Server sp_blitz-skriptet sjekker for å se om DET ER msdb-sikkerhetskopieringshistorikk eldre enn 60 dager. Dette i seg selv er ikke et problem – det kan være lurt å holde lange perioder med backup historie der bare for å gjøre ytelse gjennomstrømming rapportering – men vurdere å flytte disse dataene Til Excel eller din favoritt rapporteringsverktøy i stedet for å treffe MSDB hver gang.

Gå tilbake til sp_Blitz eller Still Oss Spørsmål

Slik Rydder Du Opp Overbelastet Msdb-Sikkerhetskopieringshistorikk

Vurder å tømme MSDB-sikkerhetskopieringshistorikken for data som er eldre enn 60 dager. Du kan gjøre dette på et par forskjellige måter:

  • du kan opprette en vedlikeholdsplan som kjører Loggoppryddingsoppgaven regelmessig.
  • du kan opprette en ENKEL SQL Server Agent-jobb som kjører sp_delete_backuphistory regelmessig (du kan også få den til å kjøre sp_purge_jobhistory hvis du vil matche funksjonaliteten for vedlikeholdsplan).

Utvid Til Noden For Vedlikeholdsplan i SSMS, høyreklikk og velg » Ny Vedlikeholdsplan…»

2015-04-10_14-20-46

Velg Vedlikeholdsoppryddingsoppgave fra Verktøykassevinduet (merk at noen ganger blir dette vinduet skjult til venstre under Objektutforsker I SSMS:

2015-04-10_14-21-26

for å fullføre, dobbeltklikk på oppgaven, velg hvilken type opprydding du vil gjøre, og hvor mye data du vil beholde. Jeg vil noen ganger opprette to oppgaver, fordi jeg bryr meg mindre Om Agentjobbhistorikk og Vedlikeholdsplanhistorikk enn jeg gjør om sikkerhetskopier, og jeg vil vanligvis at sikkerhetskopiloggen min skal samsvare med datalagringspolicyen min.

2015-04-10_14-22-03

Uansett, hvis serveren din har en stor mengde historie, vil dette trinnet ta en lang tid å kjøre første gang. Som Brent bemerket i msdb bottleneck-artikkelen, må du kanskje ty til ekstreme tiltak som å endre systemdatabasens utenlandske nøkler bare for å få slettene til å skje.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.