we hebben hier een beetje back-upgeschiedenis.

we hebben hier een beetje back-upgeschiedenis.

SQL Server volgt de geschiedenis van elke back-up. Het slaat deze gegevens op in de msdb database. Dat is een systeemdatabase, en standaard worden onze systeemdatabases opgeslagen op de C-schijf, tenzij anders aangegeven tijdens de installatie.

dit vormt gevaar op een aantal verschillende manieren:

de C-schijf kan opvullen, waardoor msdb-schrijven mislukt. Het systeemstation vult zich vaker op dan je zou denken-veroorzaakt door onzorgvuldige gebruikers die enorme bestanden downloaden naar hun bureaublad (op het systeemstation) of door Windows-Updates die veel bestanden downloaden naar een tijdelijke map op het systeemstation.

MSDB kan groeien om de C-schijf te vullen, waardoor Windows mislukt. In gevallen waarin we zeer frequente transactielogboek-back-ups maken van een groot aantal databases, en we nooit msdb zuiveren, kan deze database groeien om groot genoeg te zijn om kleine C-schijven te bedreigen. Wanneer de C-schijf vult, mislukt Windows hard.

de systeemaandrijving is vaak traag. In oude versies van SQL Server waren de systeemdatabases niet goed geïndexeerd. Combineer dit met trage lokale schijven, en we hebben een recept voor langzame msdb toegang. In één geval, tijdens onze nachtelijke back-upvensters, werd 2/3 van de tijd besteed aan het updaten van MSDB!

Monitoring tools kunnen msdb inefficiënt bevragen. We hebben gevallen gezien waar derden server monitoring tools voortdurend gecontroleerd MSDB om ervoor te zorgen dat alle databases werden steeds een back-up, maar hun query ‘ s niet indexen gebruiken. Deze query ‘ s kunnen het langzaamste ding op de server zijn.

dit deel van ons SQL Server sp_blitz script controleert om te zien of er MSDB back-up geschiedenis ouder dan 60 dagen. Dit op zich is geen probleem-u wilt misschien lange periodes van back-up geschiedenis te houden in er alleen maar om de prestaties doorvoerrapportage te doen-maar overweeg het verplaatsen van die gegevens naar Excel of uw favoriete rapportage tool in plaats van het raken van MSDB elke keer.

keer terug naar sp_Blitz of stel ons vragen

hoe op te ruimen overbelaste msdb back-up geschiedenis

overweeg het wissen van uw msdb back-up geschiedenis van gegevens ouder dan 60 dagen. Je kunt dit op een paar verschillende manieren doen:

  • u kunt een onderhoudsplan maken dat de taak voor het opruimen van de geschiedenis regelmatig uitvoert.
  • u kunt een eenvoudige taak voor SQL Server-Agent maken die sp_delete_backuphistory regelmatig uitvoert (u kunt het ook sp_purge_jobhistory laten uitvoeren als u wilt voldoen aan de functionaliteit van het onderhoudsplan).

uitbreiden naar het knooppunt onderhoudsplan in SSM ‘s, klik met de rechtermuisknop en kies “Nieuw onderhoudsplan”…”

2015-04-10_14-20-46

kies Maintenance Cleanup Task uit het gereedschapsvenster (merk op dat dit venster soms aan de linkerkant wordt verborgen onder Object Explorer in SSM ‘ s:

2015-04-10_14-21-26

om te voltooien, dubbelklik op de taak, kies het type opschoning dat u wilt doen, en hoeveel gegevens u wilt behouden. Ik zal soms maken twee taken, omdat ik geef minder Over Agent Job geschiedenis en Onderhoud Plan geschiedenis dan ik over back-ups, en ik meestal wil dat mijn back-up geschiedenis om mijn data retentie beleid te passen.

2015-04-10_14-22-03

hoe dan ook, als je server een grote hoeveelheid geschiedenis heeft, zal deze stap een loooong tijd in beslag nemen om de eerste keer te draaien. Zoals Brent opgemerkt in de msdb bottleneck artikel, je kan hebben om toevlucht te nemen tot extreme maatregelen zoals het veranderen van systeem database buitenlandse sleutels alleen maar om de verwijderingen te gebeuren.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.