Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Bases de données système SQL Server – Maintenance MSDB

Dans les articles précédents de la série Bases de données système SQL Server, nous avons passé en revue les bases de données système installées par défaut lors de l'installation de SQL Server, compris le but de chacune de ces bases de données système et exploré plus en détail la base de données Tempdb et sa maintenance. Dans cet article, nous allons explorer plus en détail la base de données MSDB ainsi que les problèmes fréquemment rencontrés autour de la base de données MSDB et comment les résoudre de la bonne manière.

La base de données MSDB

La MSDB La base de données système SQL Server stocke toutes les informations de configuration critiques et les informations historiques liées au service SQL Server Agent, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring, etc. :

  • Service de l'agent SQL Server
    • Tâches de l'Agent SQL Server :données de configuration et détails de l'historique
    • Alertes de l'Agent SQL Server – Données de configuration
    • Opérateurs SQL Server Agent – Données de configuration
    • Proxys d'agent SQL Server – Données de configuration
    • Informations associées
  • Courrier de base de données SQL Server, y compris Service Broker – Données de configuration et détails de l'historique des journaux de messagerie
  • Détails de la sauvegarde et de la restauration de SQL Server :données d'historique de tous les événements de sauvegarde et de restauration de la base de données se produisant dans l'instance de SQL Server.
  • Plans de maintenance, packages SSIS et informations associées :données de configuration, données associées et données sur l'exécution de tous ces éléments via les tâches de l'Agent SQL Server.
  • Configurations d'envoi de journaux, profils d'agents de réplication, tâches de collecteur de données :données de configuration de toutes les techniques de haute disponibilité mentionnées.

Chaque fois que l'une des configurations critiques ci-dessus est modifiée, il est recommandé d'effectuer une analyse complète sauvegarde de la base de données MSDB pour éviter toute perte de données en cas de panne.

Même si SQL Server Agent Service stocke les détails de configuration critiques dans les tables de la MSDB base de données, SQL Server stocke également quelques détails de configuration dans le registre Windows. Pour cela, il utilise la procédure stockée étendue nommée sp_set_sqlagent_properties .

Jetons un coup d'œil à l'emplacement du registre où SQL Server stocke les configurations du service SQL Server Agent. Important :Ceci est uniquement à des fins d'apprentissage et nous ne recommandons pas de modifier les valeurs de configuration. Sinon, cela pourrait entraîner des erreurs étranges liées au service SQL Server Agent.

Ouvrez l'éditeur de registre en tapant regedit dans l'invite de commande :

Cliquez sur Entrée pour ouvrir l'Éditeur du Registre :

Maintenant, accédez au chemin :

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

Consultez les détails de configuration ci-dessous. Le fragment marqué fait référence au nom de l'instance SQL Server et peut varier dans votre environnement en fonction de la version et du nom de l'instance SQL Server.

Un coup d'œil rapide sur le registre indique que certains paramètres liés au service SQL Server Agent sont stockés. Étant donné que nous ne recommandons pas de modifier les paramètres liés au service SQL Server Agent et partagés ci-dessus uniquement à des fins d'apprentissage, nous n'approfondirons pas cela ici.

Toutefois, si vous avez l'intention de modifier l'une des propriétés du service SQL Server Agent pour répondre aux exigences commerciales ou de production, vous pouvez la modifier en cliquant avec le bouton droit sur le service SQL Server Agent et en choisissant Propriétés comme indiqué ci-dessous.

Même s'il existe de nombreux paramètres disponibles liés au service SQL Server Agent et que la portée de cet article est liée à la base de données msdb, j'ai exclu ceux-ci et ne couvrant que les options spécifiques à la base de données msdb en cliquant sur le menu Historique comme indiqué ci-dessous où nous peut configurer la taille des journaux d'historique des tâches et de l'historique de l'agent.

Problèmes fréquemment rencontrés dans la base de données MSDB

Dans toute instance de production de SQL Server, de nombreux travaux de l'Agent SQL Server, des courriers de base de données, des plans de maintenance et des sauvegardes complètes/transactionnelles du journal seront activés. Selon le non. de bases de données dans l'instance ou le non. des travaux de l'Agent SQL Server disponibles ou de l'utilisation de la messagerie de base de données, notre serveur SQL commencera à enregistrer les informations d'historique de toutes les fonctionnalités activées, augmentant ainsi la taille de la MSDB base de données. S'il n'est pas correctement entretenu, cela affectera les performances de la base de données MSDB et les opérations associées.

Passons en revue les fonctionnalités décrites précédemment et les tables utilisées pour stocker les données d'historique pour comprendre comment nous pouvons garder la taille de ces tables sous contrôle.

  • Historique de sauvegarde
  • Historique des tâches de l'Agent SQL Server
  • Plans de maintenance
  • Historique des messages de la base de données SQL Server
  • Packages SSIS

Pour savoir quelles tables de la base de données MSDB occupent le plus d'espace, nous pouvons utiliser les Rapports sur l'utilisation du disque par les meilleures tables qui fait partie des rapports par défaut de SQL Server dans SQL Server Management Studio.

Ouvrez SSMS et faites un clic droit sur MSDB base de données > Rapports > Rapports standards > Utilisation du disque par les meilleures tables pour générer le rapport des tables triées par Utilisation du disque :

Cliquez sur Utilisation du disque par les meilleures tables pour afficher le rapport. Comme mon instance est une instance de développement, il n'y a pas d'énormes tables, mais ce rapport peut montrer la taille de toutes les tables d'une base de données triées par ordre décroissant.

Nous pouvons également utiliser la requête ci-dessous pour obtenir les tailles des tables dans une base de données.

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

Une fois que nous savons quelles tables occupent le plus d'espace, nous pouvons utiliser les procédures stockées associées pour contrôler leur taille.

Historique de sauvegarde

La principale responsabilité de l'administrateur de base de données est de s'assurer que les sauvegardes complètes et les journaux transactionnels sont activés sur toutes les instances de production SQL Server afin de restaurer les bases de données à un moment donné.

SQL Server stocke les détails de la sauvegarde et les informations de restauration dans les tables de base de données MSDB suivantes :

  • fichier de sauvegarde
  • groupe de fichiers de sauvegarde
  • backupmediafamily
  • jeu de médias de sauvegarde
  • sauvegarde
  • restaurer le fichier
  • restorefilegroup
  • restaurer l'historique

Pour un non significatif. des bases de données dans l'instance SQL Server configurée avec des sauvegardes complètes et des sauvegardes de journaux transactionnels, les enregistrements dans les tables ci-dessus peuvent augmenter plus rapidement.

Ainsi, SQL Server fournit deux procédures stockées système dans la MSDB base de données pour contrôler la taille des tables ci-dessus :

  • sp_delete_backuphistory - supprime les données de l'historique de sauvegarde dans les 8 tables ci-dessus basées sur la date la plus ancienne paramètre.
  • sp_delete_database_backuphistory - supprime les données de l'historique de sauvegarde dans les 8 tables ci-dessus en fonction du nom de la base de données .

La syntaxe d'exécution des procédures stockées système ci-dessus :

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

Lorsque nous exécutons l'une des procédures stockées décrites ci-dessus sur une base de données contenant d'énormes enregistrements dans les tables d'historique de sauvegarde, nous pouvons obtenir un blocage ou remarquer que les enregistrements sont supprimés très lentement. Pour résoudre ce problème, nous créons l'index manquant ci-dessous sur le backupset table. Il peut être identifié via le plan d'exécution de la procédure stockée pour exécuter n'importe laquelle de nos procédures stockées plus rapidement.

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

Historique des tâches de l'Agent SQL Server

SQL Server stocke tout l'historique des travaux de l'Agent SQL Server dans msdb.dbo.sysjobhistory table. En outre, SQL Server dispose d'une procédure stockée système nommée msdb.dbo.sp_purge_jobhistory qui aide à conserver le sysjobhistory taille de la table sous contrôle.

La syntaxe pour exécuter le sp_purge_jobhistory procédure stockée sera :

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

Les 3 paramètres sont facultatifs et nous vous recommandons d'exécuter la procédure ci-dessus en transmettant la oldest_date paramètre pour conserver le sysjobhistory taille de la table sous contrôle.

Plans d'entretien

SQL Server stocke les détails de tous les plans de maintenance dans les tableaux ci-dessous :

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

SQL Server a une procédure stockée intégrée nommée msdb.dbo.sp_maintplan_delete_log pour garder la taille de ces 2 tables sous contrôle.

La syntaxe pour exécuter la procédure sera :

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

Les 3 paramètres sont facultatifs. Nous vous recommandons d'exécuter la procédure ci-dessus, en passant le paramètre date_ancienne pour garder sous contrôle la taille des deux tables ci-dessus.

Historique des messages de la base de données SQL Server

SQL Server stocke tous les journaux d'historique de messagerie de base de données dans les tableaux ci-dessous :

  • sysmail_mailitems
  • sysmail_log
  • sysmail_attachments
  • sysmail_attachments_transfer

Pour garder ces tailles de table d'historique sous contrôle, SQL Server propose 2 procédures stockées système nommées msdb.dbo.sysmail_delete_mailitems_sp et msdb.dbo.sysmail_delete_log_sp.

La syntaxe pour exécuter ces procédures stockées sera :

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

Pour les deux procédures, tous les paramètres sont facultatifs. Cependant, il est recommandé d'utiliser le sent_before ou logged_befor e paramètres pour supprimer les anciens enregistrements en fonction de la période de conservation.

Dans quelques scénarios, si toutes les tables liées à la messagerie de base de données sont volumineuses, exécutez la commande delete procédure courra pour toujours. Un moyen plus rapide de gérer le problème consiste à supprimer la contrainte de clé étrangère sur sysmail_attachments et sysmail_send_retries tables, tronquer les 4 tables ci-dessus et recréer les 2 clés étrangères sur sysmail_attachments et sysmail_send_retries tableaux comme indiqué ci-dessous :

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

Forfaits SSIS

SQL Server stocke tous les SSIS(*.dtsx) packages dans msdb.dbo.sysssispackages table. Cette table est une table de configuration, cependant, dans des cas aléatoires, il y a de fortes chances que de nombreux packages SSIS soient déposés sur la table. Cela fait grossir la taille de cette table.

Dans ces cas, nous devons identifier s'il existe des packages indésirables et supprimer ces packages pour conserver les sysssispackages taille de la table sous contrôle.

L'essentiel

SQL Server n'a pas de tâches intégrées pour gérer la tâche de suppression dans toutes les tables discuté ci-dessus. Pourtant, nous avons le paramètre de date le plus ancien disponible pour toutes les procédures ci-dessus.

Par conséquent, l'approche recommandée pour gérer la taille de la table MSDB sous contrôle consisterait à définir une période de rétention basée sur le nombre de jours et à créer un nouveau travail de l'Agent SQL Server pour exécuter le script ci-dessous de manière planifiée :

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;

Conclusion

Nous avons découvert la liste des tables qui peuvent croître plus rapidement dans la MSDB base de données et comment garder la taille de ces tables sous contrôle. Nous avons dérivé un script pratique avec la liste des procédures à exécuter régulièrement pour empêcher le MSDB base de données de plus en plus énorme. J'espère que cet article vous sera utile pour votre automatisation et que ces informations vous libéreront l'esprit des maintenances de la base de données MSDB et vous concentreront sur d'autres activités.