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

Database di sistema di SQL Server:manutenzione di MSDB

Negli articoli precedenti della serie di database di sistema di SQL Server, abbiamo esaminato i database di sistema installati per impostazione predefinita durante l'installazione di SQL Server, compreso lo scopo di ciascuno di questi database di sistema ed esplorato il database Tempdb e la sua manutenzione in modo più dettagliato. In questo articolo, esploreremo il database MSDB in modo più dettagliato insieme ai problemi frequenti relativi al database MSDB e a come risolverli nel modo giusto.

Il database MSDB

Il MSDB Il database di sistema di SQL Server archivia tutte le informazioni di configurazione critiche e le informazioni cronologiche relative a SQL Server Agent Service, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring e così via:

  • Servizio SQL Server Agent
    • Lavori di SQL Server Agent:dati di configurazione e dettagli della cronologia
    • Avvisi di SQL Server Agent – ​​Dati di configurazione
    • Operatori di SQL Server Agent – ​​Dati di configurazione
    • Proxy di SQL Server Agent – ​​Dati di configurazione
    • Informazioni correlate
  • Posta database di SQL Server, incluso Service Broker:dati di configurazione e dettagli del registro di posta storici.
  • Dettagli di backup e ripristino di SQL Server:dati della cronologia di tutti gli eventi di backup e ripristino del database che si verificano nell'istanza di SQL Server.
  • Piani di manutenzione, pacchetti SSIS e informazioni correlate:dati di configurazione, dati correlati e dati sull'esecuzione di tutti questi elementi tramite i processi di SQL Server Agent.
  • Configurazioni log shipping, profili agente di replica, lavori di raccolta dati:dati di configurazione di tutte le tecniche di alta disponibilità citate.

Ogni volta che viene modificata una delle configurazioni critiche di cui sopra, si consiglia di eseguire un Completo backup del database MSDB per evitare qualsiasi perdita di dati in caso di errore.

Anche se SQL Server Agent Service archivia i dettagli di configurazione critici nelle tabelle in MSDB database, SQL Server memorizza alcuni dettagli di configurazione anche nel registro di Windows. Per questo, utilizza la stored procedure estesa denominata sp_set_sqlagent_properties .

Diamo una rapida occhiata al percorso del Registro di sistema in cui SQL Server archivia le configurazioni del servizio SQL Server Agent. Importante :Questo è solo a scopo di apprendimento e non consigliamo di modificare alcun valore di configurazione. In caso contrario, potrebbero verificarsi strani errori relativi al servizio SQL Server Agent.

Apri l'Editor del registro digitando regedit nel prompt dei comandi:

Fai clic su Invio per aprire l'Editor del registro :

Ora vai al percorso:

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

Visualizza i dettagli di configurazione di seguito. Il frammento contrassegnato fa riferimento al nome dell'istanza di SQL Server e potrebbe variare nell'ambiente in base alla versione di SQL Server e al nome dell'istanza.

Una rapida occhiata al Registro di sistema indica che sono presenti determinati parametri relativi al servizio SQL Server Agent archiviati. Poiché non consigliamo di modificare alcun parametro relativo al servizio SQL Server Agent e condiviso sopra solo a scopo di apprendimento, non ci addentreremo in profondità qui.

Tuttavia, se intendi modificare una qualsiasi delle proprietà del servizio SQL Server Agent per soddisfare i requisiti aziendali o di produzione, puoi modificarla facendo clic con il pulsante destro del mouse sul servizio SQL Server Agent e scegliere Proprietà come mostrato di seguito.

Anche se sono disponibili molti parametri relativi a SQL Server Agent Service e l'ambito di questo articolo è relativo al database msdb, li ho esclusi e ho coperto solo le opzioni specifiche del database msdb facendo clic sul menu Cronologia come mostrato di seguito dove può configurare la dimensione dei registri cronologia lavori e della cronologia agente.

Problemi frequenti nel database MSDB

In qualsiasi istanza di produzione di SQL Server, avremo molti processi di SQL Server Agent, messaggi di posta elettronica del database, piani di manutenzione e backup del registro completo/transazionale abilitati. A seconda del n. di database nell'istanza o il n. dei lavori di SQL Server Agent disponibili o dell'utilizzo di Database Mail, il nostro SQL Server inizierà a registrare le informazioni sulla cronologia di tutte le funzionalità abilitate, aumentando così le dimensioni del MSDB Banca dati. Se non adeguatamente mantenuto, ciò influirà sulle prestazioni del database MSDB e sulle relative operazioni.

Esaminiamo le funzionalità discusse in precedenza e le tabelle utilizzate per archiviare i dati della cronologia per capire come possiamo tenere sotto controllo le dimensioni di tali tabelle.

  • Cronologia backup
  • Cronologia processi di SQL Server Agent
  • Piani di manutenzione
  • Cronologia della posta del database di SQL Server
  • Pacchetti SSIS

Per scoprire quali tabelle nel database MSDB occupano più spazio, possiamo utilizzare i Rapporti sull'utilizzo del disco in base alle tabelle principali che fa parte del reporting predefinito di SQL Server in SQL Server Management Studio.

Apri SSMS e fai clic con il pulsante destro del mouse su MSDB database> Rapporti > Rapporti standard > Utilizzo del disco da parte delle tabelle principali per generare il report delle tabelle ordinate per Utilizzo disco:

Fai clic su Utilizzo del disco dalle tabelle principali per visualizzare il rapporto. Poiché la mia istanza è di sviluppo, non ci sono tabelle enormi, ma questo rapporto può mostrare le dimensioni di tutte le tabelle in un database ordinate in ordine decrescente.

Possiamo anche utilizzare la query seguente per ottenere le dimensioni delle tabelle all'interno di un 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

Una volta che sappiamo quali tabelle occupano più spazio, possiamo utilizzare le relative stored procedure per tenerne sotto controllo le dimensioni.

Cronologia backup

La responsabilità principale del DBA è garantire che i backup completi e i log transazionali siano abilitati in tutte le istanze di SQL Server di produzione per ripristinare i database in un determinato momento.

SQL Server archivia i dettagli del backup e le informazioni sul ripristino nelle tabelle di database MSDB seguenti :

  • file di backup
  • gruppo di file di backup
  • backupmediafamily
  • backupmediaset
  • backup
  • ripristina il file
  • restorefilegroup
  • Cronologia del ripristino

Per un significativo n. di database nell'istanza di SQL Server configurata con backup completi e backup del log transazionale, i record nelle tabelle precedenti possono aumentare più rapidamente.

Pertanto, SQL Server fornisce due stored procedure di sistema in MSDB database per controllare la dimensione delle tabelle di cui sopra:

  • sp_delete_backuphistory – elimina i dati della cronologia di backup nelle 8 tabelle precedenti in base alla data più vecchia parametro.
  • sp_delete_database_backuphistory – elimina i dati della cronologia di backup nelle 8 tabelle precedenti in base al nome del database .

La sintassi per l'esecuzione delle stored procedure di sistema sopra:

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

Quando eseguiamo una delle procedure memorizzate sopra descritte su un database contenente enormi record nelle tabelle della cronologia di backup, potremmo ottenere un blocco o notare che i record vengono eliminati molto lentamente. Per risolvere questo problema, creiamo l'indice mancante di seguito sul set di backup tavolo. Può essere identificato tramite il piano di esecuzione della procedura memorizzata per eseguire più rapidamente una qualsiasi delle nostre procedure memorizzate.

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

Cronologia processi di SQL Server Agent

SQL Server archivia tutta la cronologia dei processi di SQL Server Agent in msdb.dbo.sysjobhistory tavolo. Inoltre, SQL Server dispone di una stored procedure di sistema denominata msdb.dbo.sp_purge_jobhistory che aiuta a mantenere la sysjobhistory dimensione del tavolo sotto controllo.

La sintassi per eseguire sp_purge_jobhistory la procedura memorizzata sarà:

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

Tutti e 3 i parametri sono facoltativi e consigliamo di eseguire la procedura precedente superando la data_più_vecchia parametro per mantenere la sysjobhistory dimensione del tavolo sotto controllo.

Piani di manutenzione

SQL Server archivia i dettagli di tutti i piani di manutenzione nelle tabelle seguenti:

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

SQL Server dispone di una stored procedure integrata denominata msdb.dbo.sp_maintplan_delete_log per tenere sotto controllo le dimensioni di questi 2 tavoli.

La sintassi per eseguire la procedura sarà:

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

Tutti e 3 i parametri sono opzionali. Ti consigliamo di eseguire la procedura precedente, passando il parametro old_time per tenere sotto controllo la dimensione delle due tabelle precedenti.

Cronologia della posta del database di SQL Server

SQL Server archivia tutti i registri della cronologia di Posta elettronica database nelle tabelle seguenti:

  • sysmail_mailitems
  • sysmail_log
  • sysmail_attachments
  • sysmail_attachments_transfer

Per tenere sotto controllo queste dimensioni della tabella della cronologia, SQL Server offre 2 stored procedure di sistema denominate msdb.dbo.sysmail_delete_mailitems_sp e msdb.dbo.sysmail_delete_log_sp.

La sintassi per eseguire queste stored procedure sarà:

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

Per entrambe le procedure, tutti i parametri sono facoltativi. Tuttavia, si consiglia di utilizzare sent_before o logged_befor e parametri per eliminare i record meno recenti in base al periodo di conservazione.

In alcuni scenari, se tutte le tabelle relative a Posta elettronica database sono enormi, eseguire elimina procedura correrà per sempre. Un modo più rapido per gestire il problema è eliminare il vincolo di chiave esterna su sysmail_attachments e sysmail_send_retries tabelle, tronca le 4 tabelle precedenti e ricrea le 2 chiavi esterne su sysmail_attachments e sysmail_send_retries tabelle come mostrato di seguito:

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

Pacchetti SSIS

SQL Server archivia tutti i SSIS(*.dtsx) pacchetti nei msdb.dbo.sysssispackages tavolo. Questa tabella è una tabella di configurazione, tuttavia, in casi casuali, è probabile che ci siano molti pacchetti SSIS scaricati sulla tabella. Fa sì che le dimensioni di questa tabella diventino enormi.

In questi casi, dobbiamo identificare se ci sono pacchetti indesiderati ed eliminare quei pacchetti per mantenere i sysssispackages dimensione del tavolo sotto controllo.

Il risultato finale

SQL Server non dispone di processi integrati per gestire l'attività di eliminazione in tutte le tabelle discusso sopra. Tuttavia, abbiamo il parametro della data più vecchia disponibile per tutte le procedure di cui sopra.

Pertanto, l'approccio consigliato per gestire le dimensioni delle tabelle MSDB sotto controllo significherebbe definire un periodo di conservazione in base al numero di giorni e creare un nuovo processo di SQL Server Agent per eseguire lo script seguente in base a una pianificazione:

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;

Conclusione

Abbiamo appreso dell'elenco di tabelle che possono crescere più velocemente in MSDB database e come tenere sotto controllo la dimensione di queste tabelle. Abbiamo ricavato un pratico script con l'elenco delle procedure da eseguire regolarmente per prevenire il MSDB database che cresce fino a raggiungere dimensioni enormi. Spero che questo articolo sia utile per la tua automazione e che queste informazioni libereranno la tua mente dalle manutenzioni dei database MSDB e ti concentreranno su altre attività.