MSDB is een systeemdatabase die wordt gebruikt door SQL Server. MSDB slaat allerlei soorten gegevens op, zoals back-up- en herstelgeschiedenis, taakgeschiedenis van SQL Agent, geschiedenis van logboekverzendingsmonitor, SSIS-pakketten, Database Engine Tuning Advisor-gegevens en Service Broker-wachtrijgegevens. Net als gebruikersdatabases heeft msdb regelmatig onderhoud nodig, inclusief indexoptimalisaties en, belangrijker nog, regelmatig opschonen.
Back-up maken en geschiedenis herstellen
Standaard is er geen methode om de back-up- en herstelgeschiedenis van msdb op te schonen of te verwijderen. Het wordt voor altijd bewaard totdat u een handmatig of geautomatiseerd proces instelt om de gegevens te verwijderen. Door deze gegevens niet op te schonen, zal msdb blijven groeien, wat betekent dat het lezen van en schrijven naar die tabellen langzamer kan worden en de snelheid van uw back-uptaken kan beïnvloeden.
De meeste tools van derden en gerenommeerde onderhoudsoplossingen bevatten processen voor het wissen van back-up- en herstelgeschiedenis om te voorkomen dat dit een probleem wordt. Een gemakkelijke manier om erachter te komen of u de back-upgeschiedenis aan het opschonen bent of niet, is door rechtstreeks msdb op te vragen:
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server,
msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_finish_date,
CASE msdb..backupset.type
WHEN 'D' THEN 'Database'
WHEN 'L' THEN 'Log'
END AS backup_type
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
ORDER BY msdb.dbo.backupset.backup_finish_date; Als u een back-up- of herstelgeschiedenis heeft die meer dan 90 dagen teruggaat, moet u onderzoeken of er een wettelijke vereiste is die vereist dat u de historische informatie over die back-ups gedurende een bepaalde periode moet bewaren. Als er geen vereiste is, kunt u overwegen gegevens die ouder zijn dan een bepaalde periode te wissen. Back-upgeschiedenis is niet nodig om uw databases te herstellen, en we raden u aan deze regelmatig op te schonen om msdb op een redelijke grootte te houden. 90 dagen of minder aanhouden is het bereik dat ik gewoonlijk aan klanten aanbeveel.
Als u een proces wilt instellen om de back-up- en herstelgeschiedenis te wissen, maakt u een taak die de sp_delete_backuphistory uitvoert opgeslagen procedure in msdb en geef het een datumparameter door. De opgeslagen procedure verwijdert alle back-up- en herstelgeschiedenis die ouder is dan de datum die u opgeeft. U kunt ook een databaseonderhoudsplan maken en de taak Geschiedenis opschonen gebruiken.
Adviseur Database Engine Tuning
De Database Engine Tuning Advisor, ook wel bekend als DTA, is een tool die ontwikkelaars en databasebeheerders kunnen gebruiken om een database af te stemmen. DTA maakt gebruik van de msdb-database om de afstemgeschiedenis en andere ondersteunende objecten op te slaan.
Ik vind regelmatig overblijfselen van DTA in msdb op de productieservers van klanten. Als ik deze tabellen vind, ondervraag ik ze rechtstreeks om te bepalen of DTA nog steeds wordt gebruikt. Gelukkig heb ik nog geen klant gevonden die DTA actief gebruikt tegen productie, omdat het de prestaties aanzienlijk kan beïnvloeden. Zodra ik bevestig en met de cliënt communiceer, laat ik de DTA-tabellen van msdb vallen. In sommige gevallen maakt dit meerdere gigabytes aan ruimte vrij. Uit voorzorg neem ik ook de tijd om de prestatie-impact uit te leggen die het uitvoeren van DTA tegen productie kan veroorzaken en moedig mijn klanten aan om toekomstig gebruik op een ontwikkelingsserver te doen.
SQL Server-agent
Af en toe zal ik een klant vinden die per ongeluk het selectievakje heeft uitgeschakeld om de grootte van het taakgeschiedenislogboek te beperken. Dit is een makkelijke fout die je kunt maken als je een drukke server hebt en het logboek blijft zo snel rollen dat je geen bruikbare taakgeschiedenis hebt om naar te verwijzen bij het oplossen van problemen met SQL Server Agent-taken. Een betere benadering is om de maximale loggrootte van de taakgeschiedenis (in rijen) te verhogen tot een veel hogere waarde in plaats van deze onbeperkt te laten groeien.
In de gevallen waarin klanten onbeperkte banengroei hadden, was de sysjobhistory-tabel buitensporig groot geworden en moest deze worden opgeschoond. De beste manier om de geschiedenis te wissen is om sp_purge_jobhistory . te gebruiken en geef een datumparameter door. De opgeslagen procedure verwijdert alle taakgeschiedenis die ouder is dan de datum die u opgeeft. Als u een minimum aantal dagen SQL Server Agent-geschiedenis moet bijhouden, is het niet effectief om het taakgeschiedenislogboek te beperken op basis van rijen. Beperk in plaats daarvan de grootte van het taakgeschiedenislogboek niet en plan ook een taak die sp_purge_jobhistory uitvoert en een datumparameter doorgeeft voor het minimum aantal dagen taakgeschiedenis dat u nodig hebt. Het is gebruikelijk om een waarde van 14 of 30 dagen te hanteren.
Servicemakelaar
Onlangs kwam ik een probleem tegen met een client waarbij msdb was gegroeid tot 14 GB. Na een poging om de instantie bij te werken naar een huidig servicepack, mislukte de upgrade om de scripts op msdb toe te passen en zorgde ervoor dat msdb weer exponentieel groeide. Na wat onderzoek ontdekten we dat Service Broker was ingeschakeld voor gebeurtenismeldingen, maar niet correct was geconfigureerd. Al meer dan een jaar stonden gebeurtenismeldingen in de wachtrij, maar werden niet doorgestuurd.
Bij het controleren van de sys.transmission_queue ontdekte ik dat de servicebroker in de doeldatabase niet beschikbaar was en dat de servicebroker administratief was uitgeschakeld. Ik controleerde vervolgens welke gebeurtenismeldingen waren ingesteld door sys.server_events_notifications te ondervragen en vond slechts één item:alle foutenlogboekgebeurtenissen vastleggen. Ik vroeg toen sys.transmissions_queue om te zien hoeveel gebeurtenissen in de wachtrij stonden en vond daar enkele miljoenen records.
Nadat we dit met de klant hadden besproken en de bevindingen hadden uitgelegd, waren we het erover eens dat de beste manier van handelen was om de gebeurtenismelding te laten vallen en de huidige wachtrij te wissen door een nieuwe makelaar te creëren. Om dit te doen heb ik ALTER DATABASE msdb SET NEW_BROKER uitgevoerd. Dit gebeurde na sluitingstijd en na een goede volledige back-up van msdb.
Nadat ik de transmissiewachtrij had gewist en de gebeurtenis had verwijderd, kon ik msdb terugbrengen van 14 GB naar 300 MB. Voordat dit probleem werd verholpen, had de msdb-database de hoogste schijflatentie op de instance en had de client regelmatig last van deadlocks. Na het doorvoeren van deze wijziging en andere optimalisaties is de gebruikerservaring van de klant enorm verbeterd.
Log verzending
In het begin van mijn DBA-carrière erfde ik een consolidatieserver met een paar honderd databases die via het logbestand naar een secundaire server in een ander datacenter werden verzonden. Deze server was al enkele jaren actief en verzond de logs om de 15 minuten. Deze instantie had niet alleen last van het niet opschonen van de back-upgeschiedenis, het wist ook niet goed de logboekverzendingsmonitorgeschiedenis. Nadat ik de back-upgeschiedenis had gewist en de grootte van msdb had gecontroleerd, vertoonde het nog steeds meer gebruikte ruimte dan zou moeten. Ik heb een script uitgevoerd om me de totale grootte van elke tabel te laten zien en ontdekte dat de log_shipping_monitor_history_detail tafel was erg groot. In dit geval kon ik sp_cleanup_log_shipping_history . uitvoeren om de geschiedenis te wissen en msdb terug te brengen naar de normale grootte.
Indexeren
Het optimaliseren van indexen in msdb is net zo belangrijk als uw gebruikersdatabases. Vaak heb ik klanten gevonden die gebruikersdatabases optimaliseren, maar niet de systeemdatabases. Omdat de msdb-database intensief wordt gebruikt door SQL Server Agent, Log Shipping, Service Broker, SSIS, back-up en herstel en andere processen, kunnen de indexen zeer gefragmenteerd raken. Zorg ervoor dat uw indexoptimalisatietaken ook uw systeemdatabases bevatten, of in ieder geval msdb. Ik heb gezien dat indexoptimalisaties meerdere gigabytes aan ruimte vrijmaken van sterk gefragmenteerde indexen binnen msdb.
Samenvatting
Het negeren van msdb kan een negatieve invloed hebben op de prestaties van uw omgeving. Het is van cruciaal belang om de grootte van msdb te bewaken, evenals de processen die het gebruiken, om ervoor te zorgen dat het optimaal presteert. Back-up- en herstelgeschiedenis is de meest voorkomende reden voor het opzwellen van de msdb-database, maar Database Engine Tuning Advisor, SQL Server Agent-geschiedenis, servicebroker, logboekverzending en gebrek aan indexonderhoud kunnen allemaal bijdragen aan overmatige groei van msdb en de prestaties van de database.