sql >> Database teknologi >  >> RDS >> Sqlserver

SQL Server-systemdatabaser – MSDB-vedligeholdelse

I de tidligere artikler i SQL Server System Databases-serien har vi gennemgået de systemdatabaser, der er installeret som standard under SQL Server-installation, forstået formålet med hver af disse systemdatabaser og udforsket Tempdb-databasen og dens vedligeholdelse mere detaljeret. I denne artikel vil vi udforske MSDB-databasen mere detaljeret sammen med de ofte opståede problemer omkring MSDB-databasen, og hvordan man løser dem på den rigtige måde.

MSDB-databasen

MSDB SQL Server-systemdatabasen gemmer alle kritiske konfigurationsoplysninger og historiske oplysninger relateret til SQL Server Agent Service, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring osv.:

  • SQL Server Agent Service
    • SQL Server Agent Jobs – Konfigurationsdata og historikdetaljer
    • SQL Server Agent Alerts – Konfigurationsdata
    • SQL Server Agent Operators – Konfigurationsdata
    • SQL Server Agent Proxies – Konfigurationsdata
    • Relaterede oplysninger
  • SQL Server Database Mail, inklusive Service Broker – Konfigurationsdata og historiske Mail-logdetaljer.
  • SQL-serversikkerhedskopiering og gendannelsesdetaljer – Historikdata for alle databasesikkerhedskopierings- og gendannelsesbegivenheder, der finder sted i forekomsten af ​​SQL Server.
  • Vedligeholdelsesplaner, SSIS-pakker og relaterede oplysninger – Konfigurationsdata, relaterede data og data om udførelse af alle disse elementer via SQL Server Agent Jobs.
  • Logforsendelseskonfigurationer, replikeringsagentprofiler, dataindsamlerjob – konfigurationsdata for alle de nævnte High Availability-teknikker.

Når nogen af ​​ovenstående kritiske konfigurationer ændres, anbefales det at tage en Fuld backup af MSDB-databasen for at undgå tab af data, hvis der opstår en fejl.

Selvom SQL Server Agent Service gemmer kritiske konfigurationsdetaljer på tværs af tabeller i MSDB database, gemmer SQL Server også få konfigurationsdetaljer i Windows-registreringsdatabasen. Til det bruger den den udvidede Stored Procedure med navnet sp_set_sqlagent_properties .

Lad os tage et hurtigt kig ind i registreringsdatabasen, hvor SQL Server gemmer SQL Server Agent Service-konfigurationer. Vigtigt :Dette er kun til læringsformål, og vi anbefaler ikke at ændre nogen konfigurationsværdier. Ellers kan det ende med mærkelige fejl relateret til SQL Server Agent Service.

Åbn Registry Editor ved at skrive regedit i kommandoprompten:

Klik på Enter for at åbne Registreringseditor :

Naviger nu til stien:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13.MSSQLSERVER\SQLServerAgent

Se nedenstående konfigurationsdetaljer. Det markerede fragment refererer til SQL Server-instansens navn, og det kan variere i dit miljø baseret på SQL Server-versionen og instansnavnet.

Et hurtigt kig på registreringsdatabasen indikerer, at der er gemt visse parametre relateret til SQL Server Agent Service. Da vi ikke anbefaler at ændre nogen parametre relateret til SQL Server Agent Service og kun delt ovenfor til læringsformål, vil vi ikke dykke dybt ned i det her.

Men hvis du har til hensigt at ændre nogen af ​​SQL Server Agent Service-egenskaberne, så de opfylder forretnings- eller produktionskravene, kan du ændre dem ved at højreklikke på SQL Server Agent Service og vælge Egenskaber som vist nedenfor.

Selvom der er mange tilgængelige parametre relateret til SQL Server Agent Service, og omfanget af denne artikel er relateret til msdb-databasen, har jeg udelukket dem og kun dækket de muligheder, der er specifikke for msdb-databasen ved at klikke på menuen Historie som vist nedenfor, hvor vi kan konfigurere størrelsen på jobhistoriklogs og agenthistorik.

Ofte opståede problemer i MSDB-databasen

I enhver produktionsforekomst af SQL Server vil vi have en masse SQL Server Agent Jobs, Database Mails, Vedligeholdelsesplaner og Full/Transactional Log backups aktiveret. Afhængig af nr. af databaser i instansen eller nr. af tilgængelige SQL Server Agent-job eller Database Mail-brug, vil vores SQL Server begynde at logge historikoplysningerne for alle aktiverede funktioner og derved øge størrelsen af ​​MSDB database. Hvis det ikke vedligeholdes korrekt, vil dette påvirke MSDB-databasens ydeevne og operationer relateret til det.

Lad os gennemgå de funktioner, der er diskuteret tidligere, og de tabeller, der bruges til at gemme historikdata for at forstå, hvordan vi kan holde størrelsen på disse tabeller under kontrol.

  • Sikkerhedskopieringshistorik
  • SQL Server Agent Jobhistorik
  • Vedligeholdelsesplaner
  • SQL Server Database Mail History
  • SSIS-pakker

For at finde ud af, hvilke tabeller i MSDB-databasen, der tager mere plads, kan vi bruge Diskbrug af Top Tables-rapporter som kommer som en del af SQL Server-standardrapportering i SQL Server Management Studio.

Åbn SSMS og højreklik på MSDB database> Rapporter > Standardrapporter > Diskbrug efter toptabeller for at generere rapporten over tabeller sorteret efter Diskbrug:

Klik på Diskbrug efter toptabeller for at se rapporten. Da mit eksempel er et udviklingseksempel, er der ikke store tabeller, men denne rapport kan vise størrelsen af ​​alle tabeller i en database sorteret i faldende rækkefølge.

Vi kan også bruge nedenstående forespørgsel til at få tabellernes størrelser i en database.

SELECT -- TOP(10)
	  SCHEMA_NAME(o.[schema_id]) Schema_name
	, o.name object_name
    , total_size = CAST(SUM(au.total_pages) * 8. / 1024 AS DECIMAL(18,2))
    , total_rows = SUM(CASE WHEN i.index_id IN (0, 1) AND au.[type] = 1 THEN p.[rows] END)
FROM sys.objects o 
JOIN sys.indexes i ON o.[object_id] = i.[object_id]
JOIN sys.partitions p ON i.[object_id] = p.[object_id] AND i.index_id = p.index_id
JOIN sys.allocation_units au ON p.[partition_id] = au.container_id
WHERE i.is_disabled = 0
AND i.is_hypothetical = 0
AND o.Type in ('S','U','V')
GROUP BY o.name, SCHEMA_NAME(o.[schema_id])
ORDER BY 3 DESC

Når vi ved, hvilke tabeller der tager mere plads, kan vi bruge de relaterede lagrede procedurer til at holde deres størrelse under kontrol.

Sikkerhedskopieringshistorik

DBA's primære ansvar er at sikre, at fulde sikkerhedskopier og transaktionslogfiler er aktiveret på tværs af alle produktions SQL Server-instanser for at gendanne databaserne til et tidspunkt.

SQL Server gemmer sikkerhedskopieringsoplysningerne og gendannelsesoplysningerne i følgende MSDB-databasetabeller :

  • sikkerhedskopi
  • backupfilgruppe
  • backupmediafamily
  • backupmediesæt
  • backupset
  • gendannelsesfil
  • gendanfilgruppe
  • gendannelseshistorie

For et væsentligt nej. af databaser i SQL Server-forekomsten, der er konfigureret med fuld sikkerhedskopiering og sikkerhedskopiering af transaktionslogfiler, kan registreringer på tværs af ovenstående tabeller øges hurtigere.

SQL Server giver således to systemlagrede procedurer i MSDB database for at kontrollere størrelsen af ​​ovenstående tabeller:

  • sp_delete_backuphistory – sletter sikkerhedskopieringshistorikdata på tværs af ovenstående 8 tabeller baseret på den ældste dato parameter.
  • sp_delete_database_backuphistory – sletter sikkerhedskopieringshistorikdata på tværs af ovenstående 8 tabeller baseret på databasenavnet .

Syntaksen til at udføre ovenstående systemlagrede procedurer:

exec msdb.dbo.sp_delete_backuphistory @oldest_date = 'oldest_date'
exec msdb.dbo.sp_delete_database_backuphistory @database_name = 'database_name'

Når vi udfører nogen af ​​de lagrede procedurer, der er beskrevet ovenfor, på en database, der indeholder enorme poster på tværs af backup-historiktabellerne, kan vi blive blokeret eller bemærke, at posterne slettes meget langsomt. For at løse dette opretter vi nedenstående manglende indeks på backupsættet bord. Det kan identificeres via udførelsesplanen for den lagrede procedure for at udføre enhver af vores lagrede procedurer hurtigere.

IF NOT EXISTS (SELECT * FROM sys.indexes WHERE OBJECT_ID = OBJECT_ID('[dbo].[backupset]') AND name = 'IX_BackupSet_FinDate_MediaSet')
CREATE NONCLUSTERED INDEX IX_BackupSet_FinDate_MediaSet ON backupset(backup_finish_date) 
INCLUDE (media_set_id)
GO

SQL Server Agent Jobhistorik

SQL Server gemmer al SQL Server Agent Jobs historie i msdb.dbo.sysjobhistory bord. SQL Server har også en systemlagret procedure ved navn msdb.dbo.sp_purge_jobhistory der hjælper med at bevare sysjobhistorien bordstørrelse under kontrol.

Syntaksen til at køre sp_purge_jobhistorien gemt procedure vil være:

exec msdb.dbo.sp_purge_jobhistory @job_name = 'job_name', @job_id = 'job_id', @oldest_date ='oldest_date'

Alle 3 parametre er valgfrie, og vi anbefaler at udføre ovenstående procedure ved at sende ældste_dato parameter at beholde sysjobhistorien bordstørrelse under kontrol.

Vedligeholdelsesplaner

SQL Server gemmer detaljerne for alle vedligeholdelsesplaner i nedenstående tabeller:

  • msdb.dbo.sysmaintplan_log
  • msdb.dbo.sysmaintplan_logdetail

SQL Server har en indbygget lagret procedure ved navn msdb.dbo.sp_maintplan_delete_log for at holde styr på størrelserne på disse 2 borde.

Syntaksen til at udføre proceduren vil være:

exec msdb.dbo.sp_maintplan_delete_log @plan_id = '', @subplan_id = '', @oldest_Time = 'oldest_datetime'

Alle 3 parametre er valgfrie. Vi anbefaler, at du udfører ovenstående procedure ved at overføre parameteren oldest_time for at holde størrelsen på de to ovenstående tabeller under kontrol.

SQL Server Database Mail History

SQL Server gemmer alle Database Mail-historiklogfiler på tværs af nedenstående tabeller:

  • sysmail_mailitems
  • sysmail_log
  • sysmail_attachments
  • sysmail_attachments_transfer

For at holde disse historietabelstørrelser under kontrol tilbyder SQL Server 2 systemlagrede procedurer med navnet msdb.dbo.sysmail_delete_mailitems_sp og msdb.dbo.sysmail_delete_log_sp.

Syntaksen til at udføre disse lagrede procedurer vil være:

exec msdb.dbo.sysmail_delete_mailitems_sp @sent_before = 'oldest_datetime', @sent_status = NULL
exec msdb.dbo.sysmail_delete_log_sp @logged_before = 'oldest_datetime', @event_type = NULL

For begge procedurer er alle parametre valgfrie. Det anbefales dog at bruge sent_before eller logged_befor e parametre for at slette de ældre poster baseret på opbevaringsperioden.

I få scenarier, hvis alle tabeller relateret til Database Mail er enorme, kører du slet procedure vil køre for evigt. En hurtigere måde at håndtere problemet på er at slette begrænsningen for fremmednøgle på sysmail_attachments og sysmail_send_retries tabeller, afkort de ovenstående 4 tabeller og genskab de 2 fremmednøgler tilbage på sysmail_attachments og sysmail_send_retries tabeller som vist nedenfor:

USE MSDB;

ALTER TABLE [dbo].[sysmail_attachments] DROP [FK_sysmail_mailitems_mailitem_id];
GO
ALTER TABLE [dbo].[sysmail_send_retries] DROP [FK_mailitems_mailitem_id];
GO

TRUNCATE TABLE [dbo].[sysmail_attachments];
TRUNCATE TABLE [dbo].[sysmail_send_retries];
TRUNCATE TABLE [dbo].[sysmail_mailitems];
TRUNCATE TABLE [dbo].[sysmail_log];

ALTER TABLE [dbo].[sysmail_attachments]  WITH CHECK ADD  CONSTRAINT [FK_sysmail_mailitems_mailitem_id] FOREIGN KEY([mailitem_id])
REFERENCES [dbo].[sysmail_mailitems] ([mailitem_id])
ON DELETE CASCADE;
ALTER TABLE [dbo].[sysmail_attachments] CHECK CONSTRAINT [FK_sysmail_mailitems_mailitem_id];
GO

ALTER TABLE [dbo].[sysmail_send_retries]  WITH CHECK ADD  CONSTRAINT [FK_mailitems_mailitem_id] FOREIGN KEY([mailitem_id])
REFERENCES [dbo].[sysmail_mailitems] ([mailitem_id])
ON DELETE CASCADE;
ALTER TABLE [dbo].[sysmail_send_retries] CHECK CONSTRAINT [FK_mailitems_mailitem_id];
GO

SSIS-pakker

SQL Server gemmer alle SSIS(*.dtsx) pakker i msdb.dbo.sysssispackages bord. Denne tabel er en konfigurationstabel, men i tilfældige tilfælde er chancerne for, at der kan være mange SSIS-pakker dumpet på bordet. Det får størrelsen på dette bord til at vokse sig enormt.

I disse tilfælde skal vi identificere, om der er nogen uønskede pakker og slette disse pakker for at beholde sysssispackages bordstørrelse under kontrol.

Bundlinjen

SQL Server har ikke indbyggede job til at håndtere opgaven med at slette på tværs af alle tabeller diskuteret ovenfor. Alligevel har vi den ældste datoparameter tilgængelig for alle ovenstående procedurer.

Derfor er den anbefalede tilgang til at håndtere MSDB-tabelstørrelsen under kontrol ville være at definere en opbevaringsperiode baseret på antallet af dage og oprette et nyt SQL Server Agent-job til at udføre nedenstående script på en planlagt basis:

declare @retention_date datetime = '2021-04-01'
exec msdb.dbo.sp_delete_backuphistory @oldest_date = @retention_date;
exec msdb.dbo.sp_purge_jobhistory @oldest_date = @retention_date;
exec msdb.dbo.sp_maintplan_delete_log @oldest_Time = @retention_date;
exec msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @retention_date;
exec msdb.dbo.sysmail_delete_log_sp @logged_before = @retention_date;

Konklusion

Vi har lært om listen over tabeller, der kan vokse hurtigere i MSDB database og hvordan man holder størrelsen af ​​disse tabeller under kontrol. Vi har udledt et praktisk script med listen over procedurer, der skal udføres regelmæssigt for at forhindre MSDB database vokser til enorm størrelse også. Håber, at denne artikel vil være nyttig for din automatisering, og denne information vil frigøre dit sind fra MSDB-databasevedligeholdelse og koncentrere dig om andre aktiviteter.


  1. Lagring af krypterede data i Postgres

  2. Sådan fungerer SQLite Total()

  3. Hvordan kopierer man data fra en tabel til en anden ny tabel i MySQL?

  4. Vinduesfunktioner:sidste_værdi(ORDER BY ... ASC) samme som last_value(ORDER BY ... DESC)