Être un administrateur de base de données a de nombreuses responsabilités, et savoir ce qui se passe sur votre serveur SQL en fait partie. Être proactif et alerté des erreurs est l'un des traits qui font de quelqu'un un excellent DBA. Et je ne parle pas seulement des choses qui échouent, ce à quoi la plupart des gens pensent être alertés ; vous pouvez également être alerté des problèmes de performances. Dans SQL Server, vous avez la possibilité de créer des alertes de l'agent SQL Server (que j'appellerai désormais simplement « alertes »), et cela se fait facilement à l'aide de l'interface graphique ou de T-SQL.
Configuration des alertes de l'agent SQL Server
Pour utiliser les alertes, vous devez avoir configuré la messagerie de base de données et un opérateur d'agent SQL. La plupart des instances SQL que j'ai rencontrées ont déjà configuré la messagerie de base de données pour les notifications d'échec de travail. Si vous avez besoin de plus d'informations sur la configuration de cette fonctionnalité, consultez la rubrique de la documentation en ligne, "Configurer la messagerie de la base de données".
Une tâche moins connue est la configuration de l'opérateur. Vous pouvez créer l'opérateur à l'aide de SSMS ou de T-SQL. Dans SSMS, développez SQL Server Agent, cliquez avec le bouton droit sur Operator et choisissez New Operator. Une nouvelle boîte de dialogue s'ouvrira dans laquelle vous pourrez donner un nom à l'opérateur et spécifier l'adresse e-mail à notifier. Je préfère utiliser un groupe de distribution pour les notifications par e-mail. La plupart des entreprises ont plus d'une personne responsable de l'environnement SQL et si vous spécifiez un groupe de distribution, toute l'équipe peut être informée des alertes. L'utilisation de groupes de distribution facilite également l'ajout ou la suppression de personnes des alertes.
Vous trouverez ci-dessous un exemple de capture d'écran de la boîte de dialogue Nouvel opérateur :
Je préfère utiliser T-SQL pour m'assurer que la création de l'opérateur fait partie d'un modèle de construction de serveur. L'exemple de code pour créer l'opérateur ci-dessus est le suivant :
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
Une fois que vous avez configuré la messagerie de base de données et l'opérateur, vous pouvez créer les alertes et les affecter à l'opérateur.
Si vous utilisez SSMS, vous pouvez développer Agent SQL Server, puis Alertes. Par défaut, aucune alerte n'est créée. Si vous faites un clic droit et choisissez Nouvelle alerte, vous obtiendrez un écran similaire à la figure ci-dessous :
Vous remarquerez que sous Gravité, il y a 25 codes de gravité. Tout comme il semble, la gravité du niveau d'erreur décrit l'importance de l'erreur. La gravité 10 est informative tandis que 19-25 sont fatales et vous voudrez être averti lorsque ces erreurs se produiront. Si une erreur de gravité 23 survient, par exemple, vous avez très probablement une corruption dans l'une de vos bases de données. Ces erreurs fatales peuvent toutes avoir un impact sur les performances de votre serveur, ce qui a un impact sur l'expérience client.
Vous devez créer une alerte supplémentaire pour l'erreur 825. L'erreur 825, comme le décrit Paul Randal dans son article de blog, est liée à une opération d'E/S que SQL Server a dû réessayer mais qui a finalement réussi (alors que les erreurs 823 et 824 indiquent qu'une nouvelle tentative d'E/S a été tentée et a finalement échoué). L'erreur 825 est essentielle à connaître car elle vous alerte sur les problèmes d'E/S qui pourraient finir par devenir fatals à l'avenir. Toute nouvelle tentative est mauvaise, vous ne devez pas attendre qu'une opération d'E/S échoue à être notifiée. Si vous commencez à recevoir des messages d'erreur 825, vous devez contacter immédiatement vos équipes de stockage et de matériel.
Vous pouvez créer chacune des alertes en spécifiant le nom et en sélectionnant la gravité. Pour l'erreur 825, vous devez sélectionner Erreur et saisir le numéro. Comme avec l'opérateur, je préfère utiliser T-SQL. Si je peux facilement créer un script de processus, il est beaucoup plus facile de le réutiliser et de l'inclure dans le cadre d'une construction de serveur.
Vous trouverez ci-dessous le script que j'ai utilisé sur mon poste de travail de développeur SQL Server 2014. Ce script crée chacune des alertes et ajoute une notification pour l'alerte à l'opérateur SQL_Alerts.
EXEC msdb.dbo.sp_add_alert @name = N'Severity 19 Error', @message_id = 0, @severity = 19, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 19 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 20 Error', @message_id = 0, @severity = 20, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 20 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name=N'Severity 21 Error', @message_id = 0, @severity = 21, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 21 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 22 Error', @message_id = 0, @severity = 22, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 22 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 23 Error', @message_id = 0, @severity = 23, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 23 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 24 Error', @message_id = 0, @severity = 24, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 24 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 25 Error', @message_id = 0, @severity = 25, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 25 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Error 825', @message_id = 825, @severity = 0, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Error 825', @operator_name = N'SQL_Alerts', @notification_method = 1;
Si vous avez suivi, vous auriez configuré la messagerie de la base de données, créé un opérateur pour vous envoyer un e-mail ou un groupe de distribution sur les erreurs potentielles, et les alertes de l'agent SQL Server configurées pour la gravité 19 à 25 et l'erreur 825.
C'est bien. Chaque fois que l'une de ces alertes est déclenchée, un e-mail est envoyé à votre équipe. En plus des alertes d'événement, des alertes peuvent être configurées pour une condition de performance, comme je l'ai mentionné dans l'introduction. Par exemple, si l'utilisation de la mémoire dépasse un seuil défini, une alerte peut être déclenchée. Je vous encourage à explorer les différentes alertes de performance et à créer celles dont votre organisation pourrait bénéficier. Pour rechercher les alertes de condition de performance SQL Server, dans la nouvelle boîte de dialogue d'alerte, cliquez sur la liste déroulante Type. Vous y verrez une alerte de condition de performance SQL Server répertoriée. Une fois que vous avez choisi cette option, vous pouvez parcourir les types d'objets sur lesquels vous pouvez configurer une alerte de condition de performance.
Bien que nous ayons affecté un opérateur à la réponse à l'alerte, vous pouvez également configurer l'alerte pour exécuter une tâche SQL Agent. Bien que cela vous donne une certaine flexibilité pour avoir une tâche de réponse aux événements, cela ne permet pas d'avoir une alerte conditionnelle facile.
Utilisation de SQL Sentry pour les alertes avancées
Pour des alertes plus avancées, vous avez besoin d'un meilleur outil. C'est là que SQL Sentry peut vous aider. L'une de mes fonctionnalités d'alerte préférées de SQL Sentry est la possibilité de créer des conditions personnalisées pour alerter ou agir lorsque quelque chose a changé dans l'environnement. Par exemple, si quelqu'un modifiait la valeur de mémoire min ou max, modifiait maxdop ou le seuil de coût pour le parallélisme, vous pourriez recevoir une alerte ou même lancer un processus. Cette fonctionnalité a été introduite dans SQL Sentry v8, et Greg Gonzalez (blog | @SQLsensei) en a parlé ici :"SQL Sentry v8 :Intelligent Alerting Redefined."
Avec cette fonctionnalité, vous pouvez également créer des conditions personnalisées pour différentes bases de données au sein d'une même alerte. Si vous essayez cela en utilisant les alertes de l'Agent SQL, vous devrez créer différentes alertes par base de données.
Une autre excellente fonctionnalité d'alerte est la possibilité de créer différents calendriers d'alerte. De nombreuses organisations ont des équipes qui sont responsables à différents moments de la journée. Certains peuvent avoir le DBA de production responsable pendant la journée avec un centre d'opérations réseau couvrant le quart de nuit, puis une personne de garde le week-end. Ne serait-il pas formidable de pouvoir personnaliser un calendrier d'alertes pour informer les bonnes équipes pendant leurs heures de responsabilité ?
Vous pouvez créer des fenêtres d'alerte (comme dans une fenêtre de temps) et les lier à différentes alertes ou groupes. Cela permet à différentes alertes d'être actives à des moments différents et à différents groupes d'être notifiés à des moments différents. C'est vraiment cool car cela permet à votre alerte de suivre un calendrier d'assistance afin que les bonnes personnes soient averties. Scott Fallen détaille cette fonctionnalité dans un article de blog, "Alerting on a Call Schedule with SQL Sentry", vous expliquant comment créer des alertes pour diverses équipes d'astreinte.
Une autre fonctionnalité d'alerte de Performance Advisor et Event Manager est la possibilité de configurer d'autres réponses telles que l'exécution d'un processus Windows, la journalisation de l'événement dans une base de données ou un journal des erreurs, l'envoi d'un trap SNMP à un autre outil de surveillance tel que SCOM, ou même la suppression d'un processus. . Vos options sont presque illimitées quant à ce que vous pouvez avoir prédéfini pour qu'il se produise lorsqu'un certain événement se produit. Les alertes de l'agent SQL ne sont pas si personnalisables.
Résumé
L'important à retenir de cet article est que vous devez absolument être alerté des erreurs et des conditions de performance. Si vous ne disposez pas d'un outil tel que SQL Sentry, l'utilisation des alertes de l'agent SQL est toujours un bon début.
Au cours de mes prochains articles, je plongerai dans certaines de ces alertes ayant un impact sur les performances et discuterai des actions que vous devrez entreprendre lorsqu'elles se produiront.
