MSDB est une base de données système utilisée par SQL Server. MSDB stocke toutes sortes de données, telles que l'historique de sauvegarde et de restauration, l'historique des travaux de l'agent SQL, l'historique du moniteur d'envoi de journaux, les packages SSIS, les données de Database Engine Tuning Advisor et les données de file d'attente de Service Broker. Tout comme les bases de données utilisateur, msdb nécessite une maintenance régulière, y compris des optimisations d'index et, plus important encore, une purge régulière.
Historique de sauvegarde et de restauration
Par défaut, il n'existe aucune méthode pour purger ou supprimer l'historique de sauvegarde et de restauration de msdb. Elles sont conservées pour toujours jusqu'à ce que vous mettiez en place un processus manuel ou automatisé pour supprimer les données. En ne purgeant pas ces données, msdb continuera de croître, ce qui signifie que la lecture et l'écriture dans ces tables peuvent devenir plus lentes et avoir un impact sur la vitesse de vos tâches de sauvegarde.
La plupart des outils tiers et des solutions de maintenance réputées incluent des processus d'effacement de l'historique de sauvegarde et de restauration pour éviter que cela ne devienne un problème. Un moyen simple de savoir si vous purgez l'historique de sauvegarde ou non consiste à interroger directement msdb :
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date, CASE msdb..backupset.type WHEN 'D' THEN ' Database' WHEN 'L' THEN 'Log' END AS backup_typeFROM msdb.dbo.backupmediafamilyINNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set_idORDER BY msdb.dbo.backupset.backup_finish_date;
Si vous disposez d'un historique de sauvegarde ou de restauration datant de plus de 90 jours, vous devez rechercher s'il existe une exigence réglementaire qui vous oblige à conserver les informations historiques sur ces sauvegardes pendant une période spécifique. S'il n'y a pas d'exigence, vous devriez envisager de purger les données antérieures à une certaine période. L'historique de sauvegarde n'est pas nécessaire pour restaurer vos bases de données, et nous vous recommandons de le purger régulièrement pour conserver msdb à une taille raisonnable. Garder 90 jours ou moins est la plage que je recommande généralement aux clients.
Pour configurer un processus de purge de l'historique de sauvegarde et de restauration, créez une tâche qui exécute le sp_delete_backuphistory procédure stockée dans msdb et passez-lui un paramètre de date. La procédure stockée supprimera tout l'historique de sauvegarde et de restauration antérieur à la date que vous fournissez. Vous pouvez également créer un plan de maintenance de base de données et utiliser la tâche Nettoyer l'historique.
Conseiller de réglage du moteur de base de données
Le Database Engine Tuning Advisor, également connu sous le nom de DTA, est un outil que les développeurs et les administrateurs de base de données peuvent utiliser pour optimiser une base de données. DTA exploite la base de données msdb pour stocker l'historique de réglage et d'autres objets de support.
Je trouve régulièrement des restes de DTA dans msdb sur les serveurs de production des clients. Lorsque je trouve ces tables, je les interroge directement pour déterminer si DTA est toujours utilisé. Heureusement, je n'ai pas encore trouvé de client exécutant activement DTA contre la production, car cela peut avoir un impact significatif sur les performances. Une fois que j'ai confirmé et communiqué avec le client, je supprime les tables DTA de msdb. Dans certains cas, cela libère plusieurs gigaoctets d'espace. Par précaution, je prends également le temps d'expliquer l'impact sur les performances que l'exécution de DTA contre la production peut causer et d'encourager mes clients à ce que toute utilisation future se fasse sur un serveur de développement.
Agent SQL Server
À l'occasion, je trouverai un client qui a décoché par inadvertance la case pour limiter la taille du journal de l'historique des travaux. Il s'agit d'une erreur facile à commettre si vous avez un serveur occupé et que le journal continue de rouler si rapidement que vous n'avez aucun historique de travail utile à référencer lors du dépannage des travaux de l'Agent SQL Server. Une meilleure approche consiste à augmenter la taille maximale du journal de l'historique des tâches (en lignes) à une valeur beaucoup plus élevée plutôt que de la laisser croître sans restriction.
Dans les cas où les clients avaient une croissance illimitée de l'emploi, la table sysjobhistory était devenue excessivement volumineuse et devait être purgée. La meilleure façon de purger l'historique est d'utiliser sp_purge_jobhistory et passez un paramètre de date. La procédure stockée supprimera tout l'historique des travaux antérieur à la date que vous fournissez. Si vous devez conserver un nombre minimum de jours d'historique de l'Agent SQL Server, limiter le journal de l'historique des travaux en fonction des lignes n'est pas efficace. Au lieu de cela, ne limitez pas la taille du journal d'historique des travaux et planifiez également un travail qui exécutera sp_purge_jobhistory et transmettra un paramètre de date pour le nombre minimum de jours d'historique des travaux dont vous avez besoin. Il est courant d'utiliser une valeur de 14 ou 30 jours.
Courtier de services
Récemment, j'ai rencontré un problème avec un client où la taille de msdb était passée à 14 Go. Après une tentative de mise à jour de l'instance vers un service pack actuel, la mise à niveau a échoué lors de l'application des scripts à msdb et a provoqué une nouvelle croissance exponentielle de msdb. Après quelques recherches, nous avons découvert que Service Broker était activé pour les notifications d'événements, mais qu'il n'était pas correctement configuré. Pendant plus d'un an, les notifications d'événements étaient mises en file d'attente, mais n'étaient pas acheminées.
En vérifiant sys.transmission_queue, j'ai constaté que le courtier de services dans la base de données cible n'était pas disponible et que le courtier de services était désactivé par l'administration. J'ai ensuite vérifié quelles notifications d'événements étaient configurées en interrogeant sys.server_events_notifications et n'ai trouvé qu'une seule entrée :capturer tous les événements du journal des erreurs. J'ai ensuite interrogé sys.transmissions_queue pour voir combien d'événements se trouvaient dans la file d'attente et j'y ai trouvé plusieurs millions d'enregistrements.
Après en avoir discuté avec le client et expliqué les résultats, nous avons convenu que la meilleure solution était de supprimer la notification d'événement et d'effacer la file d'attente actuelle en créant un nouveau courtier. Pour ce faire, j'ai exécuté ALTER DATABASE msdb SET NEW_BROKER. Cela a été fait après des heures et après une bonne sauvegarde complète de msdb.
Après avoir effacé la transmission_queue et supprimé l'événement, j'ai pu réduire msdb de 14 Go à 300 Mo. Avant de corriger ce problème, la base de données msdb avait la latence de disque la plus élevée sur l'instance et le client rencontrait des blocages réguliers. Après la mise en œuvre de ce changement, ainsi que d'autres optimisations, l'expérience utilisateur du client s'est grandement améliorée.
Envoi de journaux
Au début de ma carrière de DBA, j'ai hérité d'un serveur de consolidation qui avait quelques centaines de bases de données qui étaient Log Shipped vers un serveur secondaire dans un autre centre de données. Ce serveur était opérationnel depuis plusieurs années et envoyait les journaux toutes les 15 minutes. Non seulement cette instance souffrait de ne pas purger l'historique de sauvegarde, mais elle n'effaçait pas correctement l'historique du moniteur d'envoi de journaux. Une fois que j'ai purgé l'historique de sauvegarde et vérifié la taille de msdb, il affichait toujours plus d'espace utilisé qu'il ne le devrait. J'ai exécuté un script pour me montrer la taille totale de chaque table et j'ai trouvé que le log_shipping_monitor_history_detail la table était très grande. Dans ce cas, j'ai pu exécuter sp_cleanup_log_shipping_history pour purger l'historique et ramener msdb à sa taille normale.
Indexation
L'optimisation des index dans msdb est tout aussi importante que vos bases de données utilisateur. Plusieurs fois, j'ai trouvé des clients qui optimisent les bases de données utilisateur mais pas les bases de données système. Étant donné que la base de données msdb est fortement utilisée par l'agent SQL Server, l'envoi de journaux, Service Broker, SSIS, la sauvegarde et la restauration et d'autres processus, les index peuvent être très fragmentés. Assurez-vous que vos tâches d'optimisation d'index incluent également vos bases de données système, ou au moins msdb. J'ai vu des optimisations d'index libérer plusieurs gigaoctets d'espace à partir d'index hautement fragmentés dans msdb.
Résumé
Négliger msdb peut avoir un impact négatif sur les performances de votre environnement. Il est crucial de surveiller la taille de msdb, ainsi que les processus qui l'utilisent, pour s'assurer qu'il fonctionne de manière optimale. L'historique de sauvegarde et de restauration est la raison la plus courante du gonflement de la base de données msdb, mais l'assistant de réglage du moteur de base de données, l'historique de l'agent SQL Server, le courtier de services, l'envoi de journaux et le manque de maintenance de l'index peuvent tous contribuer à une croissance excessive de msdb et avoir un impact sur les performances de la base de données.
