I de tidigare artiklarna i serien SQL Server System Databases har vi gått igenom systemdatabaserna som installeras som standard under installationen av SQL Server, förstått syftet med var och en av dessa systemdatabaser och utforskat Tempdb-databasen och dess underhåll mer i detalj. I den här artikeln kommer vi att utforska MSDB-databasen mer i detalj tillsammans med de vanligaste problemen kring MSDB-databasen och hur man löser dem på rätt sätt.
MSDB-databasen
MSDB SQL Server-systemdatabasen lagrar all kritisk konfigurationsinformation och historisk information relaterad till SQL Server Agent Service, SQL Server Service Broker, Databas Mail, Log Shipping, Database Mirroring, etc.:
- SQL Server Agent Service
- SQL Server Agent Jobs – Konfigurationsdata och historikdetaljer
- SQL Server Agent Alerts – Konfigurationsdata
- SQL Server Agent Operatörer – Konfigurationsdata
- SQL Server Agent Proxies – Konfigurationsdata
- Relaterad information
- SQL Server Database Mail, inklusive Service Broker – Konfigurationsdata och historiska Mail-loggdetaljer.
- SQL Server Backup and Restore detaljer – Historikdata för alla databasbackup och återställningshändelser som inträffar i instansen av SQL Server.
- Underhållsplaner, SSIS-paket och relaterad information – Konfigurationsdata, relaterade data och data om exekvering av alla dessa objekt via SQL Server Agent Jobs.
- Konfigurationer för loggfrakt, replikeringsagentprofiler, datainsamlarjobb – Konfigurationsdata för alla nämnda tekniker med hög tillgänglighet.
När någon av ovanstående kritiska konfigurationer ändras, rekommenderas att du tar en Fullständig säkerhetskopiering av MSDB-databasen för att undvika dataförlust om ett fel inträffar.
Även om SQL Server Agent Service lagrar kritiska konfigurationsdetaljer över tabeller i MSDB databas lagrar SQL Server några konfigurationsdetaljer i Windows-registret också. För det använder den den utökade lagrade proceduren som heter sp_set_sqlagent_properties .
Låt oss ta en snabb titt på registret där SQL Server lagrar SQL Server Agent Service-konfigurationer. Viktigt :Detta är endast för inlärningssyfte, och vi rekommenderar inte att du ändrar några konfigurationsvärden. Annars kan det sluta med konstiga fel relaterade till SQL Server Agent Service.
Öppna Registerredigeraren genom att skriva regedit i kommandotolken:
Klicka på Enter för att öppna Registerredigeraren :
Navigera nu till sökvägen:
Dator\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13.MSSQLSERVER\SQLServerAgent
Se nedanstående konfigurationsdetaljer. Det markerade fragmentet hänvisar till SQL Server-instansens namn, och det kan variera i din miljö baserat på SQL Server-versionen och instansnamnet.
En snabb titt på registret indikerar att det finns vissa parametrar relaterade till SQL Server Agent Service lagrade. Eftersom vi inte rekommenderar att du ändrar några parametrar som är relaterade till SQL Server Agent Service och som delas ovan endast i lärande syfte, kommer vi inte att fördjupa oss i det här.
Men om du har för avsikt att ändra någon av SQL Server Agent Service-egenskaperna för att möta affärs- eller produktionskrav, kan du ändra den genom att högerklicka på SQL Server Agent Service och välja Egenskaper som visas nedan.
Även om det finns många tillgängliga parametrar relaterade till SQL Server Agent Service och omfattningen av den här artikeln är relaterad till msdb-databasen, har jag uteslutit dessa och täcker endast de alternativ som är specifika för msdb-databasen genom att klicka på Historik-menyn som visas nedan där vi kan konfigurera storleken på jobbhistorikloggar och agenthistorik.
Vanliga problem i MSDB-databasen
I alla produktionsinstanser av SQL Server kommer vi att ha många SQL Server Agent Jobs, Databas Mails, Underhållsplaner och Full/Transactional Log backups aktiverade. Beroende på nr. av databaser i instansen eller nr. av tillgängliga SQL Server Agent-jobb, eller Databas Mail-användning, kommer vår SQL Server att börja logga historikinformationen för alla aktiverade funktioner och därigenom öka storleken på MSDB databas. Om det inte underhålls på rätt sätt kommer detta att påverka MSDB-databasens prestanda och operationer relaterade till det.
Låt oss granska funktionerna som diskuterats tidigare och tabellerna som används för att lagra historikdata för att förstå hur vi kan hålla storleken på dessa tabeller under kontroll.
- Säkerhetskopieringshistorik
- SQL Server Agent Jobbhistorik
- Underhållsplaner
- SQL Server Databas Mail History
- SSIS-paket
För att ta reda på vilka tabeller i MSDB-databasen som tar mer utrymme kan vi använda Rapporterna Diskanvändning av Top Tables som kommer som en del av SQL Servers standardrapportering i SQL Server Management Studio.
Öppna SSMS och högerklicka på MSDB databas> Rapporter > Standardrapporter > Diskanvändning efter topptabeller för att generera rapporten över tabeller sorterade efter Diskanvändning:
Klicka på Diskanvändning efter topptabeller för att se rapporten. Eftersom min instans är en utvecklingsinstans, finns det inga stora tabeller, men den här rapporten kan visa storleken på alla tabeller i en databas sorterade i fallande ordning.
Vi kan också använda frågan nedan för att få tabellernas storlek i en databas.
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 väl vet vilka tabeller som tar mer plats kan vi använda de relaterade lagrade procedurerna för att hålla deras storlek under kontroll.
Säkerhetskopieringshistorik
DBA:s primära ansvar är att säkerställa att fullständiga säkerhetskopior och transaktionsloggar är aktiverade för alla produktions-SQL Server-instanser för att återställa databaserna till en viss tidpunkt.
SQL Server lagrar säkerhetskopieringsinformationen och återställningsinformationen i följande MSDB-databastabeller :
- säkerhetskopieringsfil
- backupfilegroup
- backupmediafamily
- backupmediaset
- säkerhetskopiering
- återställningsfil
- återställningsfilgrupp
- återställningshistorik
För ett betydande nej. av databaser i SQL Server-instansen som konfigurerats med fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar, kan poster över tabellerna ovan öka snabbare.
Sålunda tillhandahåller SQL Server två systemlagrade procedurer i MSDB databas för att kontrollera storleken på ovanstående tabeller:
- sp_delete_backuphistory – tar bort säkerhetskopieringshistoriken över de åtta tabellerna ovan baserat på det äldsta datumet parameter.
- sp_delete_database_backuphistory – tar bort säkerhetskopieringshistoriken över de åtta tabellerna ovan baserat på databasnamnet .
Syntaxen för att utföra ovanstående systemlagrade 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 kör någon av de lagrade procedurerna som beskrivs ovan på en databas som innehåller enorma poster över säkerhetskopieringshistoriktabellerna, kan vi få blockering eller märka att posterna raderas mycket långsamt. För att lösa detta skapar vi nedanstående saknade index på backupset tabell. Det kan identifieras via exekveringsplanen för den lagrade proceduren för att exekvera någon av våra lagrade procedurer snabbare.
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 Jobbhistorik
SQL Server lagrar all SQL Server Agent Jobs-historik i msdb.dbo.sysjobhistory tabell. SQL Server har också en systemlagrad procedur som heter msdb.dbo.sp_purge_jobhistory som hjälper till att behålla sysjobhistorien bordsstorlek under kontroll.
Syntaxen för att köra sp_purge_jobhistory lagrad procedur kommer att vara:
exec msdb.dbo.sp_purge_jobhistory @job_name = 'job_name', @job_id = 'job_id', @oldest_date ='oldest_date'Alla tre parametrarna är valfria, och vi rekommenderar att du utför proceduren ovan genom att skicka äldsta_datum parameter för att behålla sysjobhistoriken bordsstorlek under kontroll.
Underhållsplaner
SQL Server lagrar information om alla underhållsplaner i tabellerna nedan:
- msdb.dbo.sysmaintplan_log
- msdb.dbo.sysmaintplan_logdetail
SQL Server har en inbyggd lagrad procedur som heter msdb.dbo.sp_maintplan_delete_log för att hålla storleken på dessa 2 bord under kontroll.
Syntaxen för att utföra proceduren kommer att vara:
exec msdb.dbo.sp_maintplan_delete_log @plan_id = '', @subplan_id = '', @oldest_Time = 'oldest_datetime'Alla tre parametrarna är valfria. Vi rekommenderar att du utför proceduren ovan och skickar parametern oldest_time för att hålla storleken på ovanstående två tabeller under kontroll.
SQL Server Databas Mail History
SQL Server lagrar alla historikloggar för Database Mail i nedanstående tabeller:
- sysmail_mailitems
- sysmail_log
- sysmail_attachments
- sysmail_attachments_transfer
För att hålla dessa historiktabellstorlekar under kontroll, erbjuder SQL Server två lagrade systemprocedurer som heter msdb.dbo.sysmail_delete_mailitems_sp och msdb.dbo.sysmail_delete_log_sp.
Syntaxen för att exekvera dessa lagrade procedurer kommer att vara:
exec msdb.dbo.sysmail_delete_mailitems_sp @sent_before = 'oldest_datetime', @sent_status = NULLexec msdb.dbo.sysmail_delete_log_sp @logged_before = 'oldest_datetime', @event_type = NULLFör båda procedurerna är alla parametrar valfria. Det rekommenderas dock att använda sent_before eller logged_befor e parametrar för att radera äldre poster baserat på lagringsperioden.
I få scenarier, om alla tabeller relaterade till Databas Mail är enorma, kör du delete procedur kommer att springa för alltid. Ett snabbare sätt att hantera problemet är att ta bort begränsningen för främmande nyckel på sysmail_attachments och sysmail_send_retries tabeller, trunkera ovanstående 4 tabeller och återskapa de 2 främmande nycklarna på sysmail_attachments och sysmail_send_retries tabeller som visas nedan:
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-paket
SQL Server lagrar alla SSIS(*.dtsx) paket i msdb.dbo.sysssispackages tabell. Den här tabellen är en konfigurationstabell, men i slumpmässiga fall är chansen stor att det kan finnas många SSIS-paket dumpade på bordet. Det gör att storleken på det här bordet växer enormt.
I dessa fall måste vi identifiera om det finns några oönskade paket och ta bort dessa paket för att behålla sysssispackages bordsstorlek under kontroll.
Slutet
SQL Server har inte inbyggda jobb för att hantera uppgiften att ta bort från alla tabeller diskuterats ovan. Ändå har vi den äldsta datumparametern tillgänglig för alla ovanstående procedurer.
Därför är den rekommenderade metoden för att hantera MSDB-tabellstorleken under kontroll skulle vara att definiera en lagringsperiod baserat på antalet dagar och skapa ett nytt SQL Server Agent-jobb för att exekvera nedanstående skript på en schemalagd 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;
Slutsats
Vi har lärt oss om listan över tabeller som kan växa snabbare i MSDB databas och hur man håller storleken på dessa tabeller under kontroll. Vi har tagit fram ett praktiskt skript med listan över procedurer som ska köras regelbundet för att förhindra MSDB databasen växer till enorm storlek också. Hoppas att den här artikeln kommer att vara till hjälp för din automatisering och att denna information kommer att befria dig från MSDB-databasunderhåll och koncentrera dig på andra aktiviteter.