SQL Server-systeemdatabases

In de vorige artikelen van de serie SQL Server-systeemdatabases hebben we de systeemdatabases doorgenomen die standaard worden geïnstalleerd tijdens de installatie van SQL Server, hebben we het doel van elk van die systeemdatabases begrepen en hebben we de Tempdb-database en het onderhoud ervan in meer detail onderzocht. In dit artikel gaan we dieper in op de MSDB-database, de veelvoorkomende problemen rond de MSDB-database en hoe u deze op de juiste manier kunt oplossen.

De MSDB-database

De MSDB SQL Server-systeemdatabase slaat alle kritieke configuratie-informatie en historische informatie op met betrekking tot SQL Server Agent Service, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring, enz.:

SQL Server Agent-service
- SQL Server Agent-taken - Configuratiegegevens en geschiedenisdetails
- SQL Server Agent-waarschuwingen – Configuratiegegevens
- SQL Server Agent-operators – Configuratiegegevens
- SQL Server Agent Proxy's – Configuratiegegevens
- Verwante informatie
SQL Server Database Mail, inclusief Service Broker – Configuratiegegevens en historische Mail-loggegevens.
SQL Server back-up- en herstelgegevens – Geschiedenisgegevens van alle databaseback-up- en herstelgebeurtenissen die plaatsvinden in het exemplaar van SQL Server.
Onderhoudsplannen, SSIS-pakketten en gerelateerde informatie:configuratiegegevens, gerelateerde gegevens en de gegevens over de uitvoering van al deze items via SQL Server Agent-taken.
Verzendconfiguraties loggen, profielen van replicatieagenten, taken voor gegevensverzamelaars - Configuratiegegevens van alle genoemde technieken voor hoge beschikbaarheid.

Telkens wanneer een van de bovenstaande kritieke configuraties wordt gewijzigd, wordt aanbevolen om een Volledige back-up van de MSDB-database om gegevensverlies te voorkomen als er een storing optreedt.

Hoewel SQL Server Agent Service kritieke configuratiegegevens opslaat in tabellen in de MSDB database, slaat SQL Server ook weinig configuratiedetails op in het Windows-register. Daarvoor gebruikt het de uitgebreide Stored Procedure genaamd sp_set_sqlagent_properties .

Laten we eens kijken naar de registerlocatie waar SQL Server SQL Server Agent Service-configuraties opslaat. Belangrijk :Dit is alleen voor leerdoeleinden en we raden af om configuratiewaarden te wijzigen. Anders kan het leiden tot rare fouten met betrekking tot SQL Server Agent Service.

Open de Register-editor door regedit . te typen in de opdrachtprompt:

Klik op Enter om de Register-editor te openen :

Navigeer nu naar het pad:

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

Bekijk de onderstaande configuratiedetails. Het gemarkeerde fragment verwijst naar de naam van de SQL Server-instantie en kan in uw omgeving verschillen op basis van de SQL Server-versie en de instantienaam.

Een snelle blik op het register geeft aan dat er bepaalde parameters met betrekking tot SQL Server Agent Service zijn opgeslagen. Aangezien we niet aanbevelen om parameters met betrekking tot de SQL Server Agent-service te wijzigen en hierboven alleen voor leerdoeleinden te delen, zullen we er hier niet diep op ingaan.

Als u echter van plan bent om de eigenschappen van de SQL Server Agent Service te wijzigen om te voldoen aan de zakelijke of productievereisten, kunt u deze wijzigen door met de rechtermuisknop op de SQL Server Agent Service te klikken en Eigenschappen te kiezen. zoals hieronder weergegeven.

Hoewel er veel parameters beschikbaar zijn met betrekking tot SQL Server Agent Service en de reikwijdte van dit artikel gerelateerd is aan de msdb-database, heb ik deze uitgesloten en alleen de opties behandeld die specifiek zijn voor de msdb-database door op het menu Geschiedenis te klikken, zoals hieronder weergegeven, waar we kan de grootte van taakgeschiedenislogboeken en agentgeschiedenis configureren.

Veelvoorkomende problemen in MSDB-database

In elk productie-exemplaar van SQL Server hebben we veel SQL Server Agent Jobs, Database Mails, Onderhoudsplannen en Full/Transactional Log-back-ups ingeschakeld. Afhankelijk van het nr. van databases in de instantie of de nr. beschikbare SQL Server Agent-taken of het gebruik van Database Mail, onze SQL Server begint met het loggen van de geschiedenisinformatie van alle ingeschakelde functies, waardoor de grootte van de MSDB wordt vergroot. databank. Als dit niet goed wordt onderhouden, heeft dit invloed op de prestaties van de MSDB-database en daarmee verband houdende bewerkingen.

Laten we eens kijken naar de functies die eerder zijn besproken en de tabellen die zijn gebruikt om geschiedenisgegevens op te slaan om te begrijpen hoe we de grootte van die tabellen onder controle kunnen houden.

Back-upgeschiedenis
Geschiedenis van SQL Server Agent-taken
Onderhoudsplannen
SQL Server Database E-mailgeschiedenis
SSIS-pakketten

Om erachter te komen welke tabellen in de MSDB-database meer ruimte innemen, kunnen we de Disk Usage by Top Tables Reports gebruiken die deel uitmaakt van de standaardrapportage van SQL Server in SQL Server Management Studio.

Open SSMS en klik met de rechtermuisknop op MSDB database> Rapporten > Standaardrapporten > Schijfgebruik door toptabellen om het rapport van tabellen te genereren, gesorteerd op schijfgebruik:

Klik op Schijfgebruik door Top Tables om het rapport te bekijken. Aangezien mijn exemplaar een ontwikkelingsexemplaar is, zijn er geen enorme tabellen, maar dit rapport kan de grootte van alle tabellen in een database weergeven, gesorteerd in aflopende volgorde.

We kunnen ook de onderstaande query gebruiken om de afmetingen van de tabellen in een database te krijgen.

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

Zodra we weten welke tabellen meer ruimte innemen, kunnen we de gerelateerde opgeslagen procedures gebruiken om hun grootte onder controle te houden.

Back-upgeschiedenis

De primaire verantwoordelijkheid van de DBA is ervoor te zorgen dat volledige back-ups en transactielogboeken zijn ingeschakeld voor alle productie-SQL Server-instanties om de databases op een bepaald moment te herstellen.

SQL Server slaat de back-upgegevens en de herstelgegevens op in de volgende MSDB-databasetabellen :

back-upbestand
back-upbestandsgroep
backupmediafamilie
back-upmediaset
backup
bestand herstellen
bestandsgroep herstellen
geschiedenis herstellen

Voor een belangrijk nee. van databases in de SQL Server-instantie geconfigureerd met volledige back-ups en transactielogboekback-ups, kunnen records in de bovenstaande tabellen sneller toenemen.

SQL Server biedt dus twee door het systeem opgeslagen procedures in de MSDB database om de grootte van de bovenstaande tabellen te bepalen:

sp_delete_backuphistory – verwijdert de back-upgeschiedenisgegevens in de bovenstaande 8 tabellen op basis van de oudste datum parameter.
sp_delete_database_backuphistory – verwijdert de back-upgeschiedenisgegevens in de bovenstaande 8 tabellen op basis van de databasenaam .

De syntaxis voor het uitvoeren van de bovenstaande door het systeem opgeslagen procedures:

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

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

Wanneer we een van de hierboven beschreven opgeslagen procedures uitvoeren op een database met enorme records in de back-upgeschiedenistabellen, kunnen we blokkering krijgen of merken dat de records heel langzaam worden verwijderd. Om dit op te lossen, maken we de onderstaande ontbrekende index op de backupset tafel. Het kan worden geïdentificeerd via het uitvoeringsplan van de opgeslagen procedure om een van onze opgeslagen procedures sneller uit te voeren.

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

Geschiedenis van SQL Server Agent-taken

SQL Server slaat alle geschiedenis van SQL Server Agent-taken op in de msdb.dbo.sysjobhistory tafel. Bovendien heeft SQL Server een door het systeem opgeslagen procedure met de naam msdb.dbo.sp_purge_jobhistory dat helpt om de sysjobhistory . te behouden tafelgrootte onder controle.

De syntaxis om de sp_purge_jobhistory . uit te voeren opgeslagen procedure zal zijn:

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

Alle 3 parameters zijn optioneel, en we raden aan om de bovenstaande procedure uit te voeren door de oldest_date door te geven parameter om de sysjobhistory . te behouden tafelgrootte onder controle.

Onderhoudsplannen

SQL Server slaat de details van alle Onderhoudsplannen op in de onderstaande tabellen:

msdb.dbo.sysmaintplan_log
msdb.dbo.sysmaintplan_logdetail

SQL Server heeft een ingebouwde opgeslagen procedure met de naam msdb.dbo.sp_maintplan_delete_log om de afmetingen van deze 2 tabellen onder controle te houden.

De syntaxis om de procedure uit te voeren is:

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

Alle 3 parameters zijn optioneel. We raden u aan de bovenstaande procedure uit te voeren, waarbij u de parameter oudste_time doorgeeft om de grootte van de bovenstaande twee tabellen onder controle te houden.

SQL Server Database E-mailgeschiedenis

SQL Server slaat alle geschiedenislogboeken van Database Mail op in de onderstaande tabellen:

sysmail_mailitems
sysmail_log
sysmail_attachments
sysmail_attachments_transfer

Om de grootte van deze geschiedenistabellen onder controle te houden, biedt SQL Server 2 opgeslagen systeemprocedures genaamd msdb.dbo.sysmail_delete_mailitems_sp en msdb.dbo.sysmail_delete_log_sp.

De syntaxis om deze opgeslagen procedures uit te voeren is:

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

Voor beide procedures zijn alle parameters optioneel. Het wordt echter aanbevolen om de sent_before . te gebruiken of logged_befor e parameters om de oudere records te verwijderen op basis van de bewaarperiode.

In enkele scenario's, als alle tabellen met betrekking tot Database Mail enorm zijn, is het uitvoeren van de delete procedure zal voor altijd lopen. Een snellere manier om het probleem op te lossen, is door de beperking voor een externe sleutel op sysmail_attachments te verwijderen. en sysmail_send_retries tabellen, kap de bovenstaande 4 tabellen af en maak de 2 externe sleutels opnieuw aan op sysmail_attachments en sysmail_send_retries tafels zoals hieronder weergegeven:

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-pakketten

SQL Server slaat alle SSIS(*.dtsx) . op pakketten in de msdb.dbo.sysssispakketten tafel. Deze tabel is een configuratietabel, maar in willekeurige gevallen is de kans groot dat er veel SSIS-pakketten op de tabel worden gedumpt. Het zorgt ervoor dat de grootte van deze tafel enorm wordt.

In die gevallen moeten we vaststellen of er ongewenste pakketten zijn en die pakketten verwijderen om de sysssispakketten te behouden tafelgrootte onder controle.

Waar het op neerkomt

SQL Server heeft geen ingebouwde taken om de taak van verwijderen over alle tabellen af te handelen hierboven besproken. Toch hebben we de oudste datumparameter beschikbaar voor alle bovenstaande procedures.

Vandaar de aanbevolen benadering om de MSDB-tabelgrootte onder controle te houden zou zijn om een bewaarperiode te definiëren op basis van het aantal dagen, en een nieuwe SQL Server Agent-taak te creëren om het onderstaande script op een geplande basis uit te voeren:

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;

Conclusie

We hebben geleerd over de lijst met tabellen die sneller kunnen groeien in de MSDB database en hoe u de grootte van deze tabellen onder controle kunt houden. We hebben een handig script afgeleid met de lijst met procedures die regelmatig moeten worden uitgevoerd om de MSDB . te voorkomen database groeit ook tot enorme omvang. Ik hoop dat dit artikel nuttig zal zijn voor uw automatisering en dat deze informatie u zal bevrijden van het onderhoud aan de MSDB-database en u zal concentreren op andere activiteiten.

SQL Server-systeemdatabases - MSDB-onderhoud