Les alertes Les alertes vont être définies afin de déclencher un traitement automatique pour corriger le problème et/ou avertir un opérateur qui sera en mesure d agir rapidement afin de résoudre le problème. 1. Présentation Lors du fonctionnement du serveur, des erreurs, des messages ou des événements générés par SQL Server sont inscrits dans l observateur des événements de Windows. L agent SQL Server va lire le journal application à la recherche des informations qu il est en mesure de traiter en les comparant aux alertes qui sont définies dans la table sysalerts de la base msdb. Une alerte peut également être déclenchée suite au dépassement d une valeur limite (fixée) par un compteur de performance. Enfin une alerte peut être déclenchée suite à un évènement WMI (Windows Management Instrumentation) particulier. Dans ce dernier cas, l agent SQL Server est un client de l espace de noms WMI et lors de la définition de l alerte, il est nécessaire de spécifier l évènement WMI qui va déclencher l alerte. Les alertes associées à une erreur SQL Server sont les plus fréquentes. a. Comment inscrire une information dans le journal application? Trois types d événement sont inscrits dans l observateur des événements : les messages dont le niveau de gravité et supérieur à 19. Les messages sont stockés dans la table sysmessages de la base Master. Pour forcer un message dont le niveau de gravité est inférieur à 19 à s inscrire dans le journal, il faut exécuter la procédure sp_altermessage. toutes les instructions RAISERROR avec l option WITH LOG. tout événement consigné avec xp_logevent. La taille du journal application de l observateur des événements de Windows doit être suffisante pour contenir tous les messages. b. Comment réagit l agent SQL Server? L agent SQL parcourt le journal application à la recherche des messages provenant de SQL Server. Il compare alors l erreur avec les alertes définies dans la table sysalerts qui est conservée dans le cache pour améliorer les performances. Cette alerte déclenche l exécution d une tâche planifiée et/ou la notification d opérateur. 2. Gestion des alertes Chaque alerte possède un nom qui est unique. Ce nom est limité à 128 caractères. Seuls les messages inscrits dans l observateur des événements peuvent déclencher une alerte. a. En réponse à des erreurs SQL Server Sur des erreurs SQL Server il est possible de lier une alerte soit au numéro de l erreur, soit à la gravité. Si pour un événement donné (n d erreur et niveau de gravité), deux alertes peuvent se déclencher, alors l agent SQL Server exécutera l erreur la plus spécifique possible, dans ce cas celle liée au numéro d erreur. En réponse à un événement une seule alerte au plus peut être déclenchée. Avant de créer une alerte, il faut prendre en considération les critères suivants : - 1 -
le numéro d erreur doit être inscrit dans l observateur des événements si on souhaite le déclenchement d une alerte. le niveau de gravité peut être le facteur qui déclenche l alerte. Seules les erreurs disposant d un niveau de gravité situé entre 19 et 25 sont inscrites automatiquement dans l observateur des événements. Les niveaux 20 à 25 correspondent à des erreurs irrécupérables, il faut donc toujours définir l opérateur à prévenir en cas d erreur de ce type. Les alertes fournies en exemple par SQL Server correspondent à la gestion de ces niveaux de gravité. la base de données : il est possible de préciser la base à l origine de l événement afin de spécialiser les alertes. On peut ainsi créer plusieurs alertes pour un même numéro d erreur. texte de l événement : toujours dans le but de limiter les déclenchements d alertes il est possible de préciser le texte que doit contenir le message de l événement. b. Le transfert d événements Il est possible, en se basant sur un niveau de gravité, de transférer tous les messages qui possèdent un niveau de gravité supérieur ou égal vers un autre serveur SQL 2008. Le transfert d événements peut être utilisé afin de centraliser le traitement des alertes pour un groupe de serveurs exécutant SQL Server 2008. Avantages La centralisation permet une gestion simplifiée des alertes. L administration d un serveur SQL supplémentaire demande une charge de travail moindre pour l administrateur. Le temps de mise en œuvre est réduit car toutes les alertes ne sont définies qu une seule fois. Inconvénients Le transfert d événements augmente le trafic réseau. Point de défaillance unique. Le serveur qui traite toutes les alertes subit une charge de travail importante et est moins disponible pour le traitement des données qu il gère. Mise en œuvre La désignation d un serveur de transfert peut se faire uniquement au moyen de SQL Server Management Studio, depuis la fenêtre des propriétés du service SQL Server Agent. - 2 -
c. Mise en place SQL Server Management Studio Pour définir une nouvelle alerte, il faut sélectionner Nouvelle alerte depuis le menu contextuel associé au nœud Agent SQL Server Alertes de l explorateur d objets. - 3 -
Il reste à compléter cette boîte de dialogue en y précisant le nom de l alerte, son attachement à un numéro d erreur ou un niveau de gravité. Il est possible de restreindre la portée de l alerte en spécifiant une base de données ou le texte que doit contenir l événement. - 4 -
La page Réponse permet de préciser ce que doit faire l alerte. Il est possible de préciser un travail à exécuter et les opérateurs à prévenir. Pour chaque opérateur, il convient de préciser le moyen utilisé pour le prévenir. Les notifications aux opérateurs comportent le texte qui est précisé au niveau de l alerte. Activation/Désactivation de l alerte C est par l intermédiaire des Propriétés de l alerte qu il sera possible de la désactiver ou de la réactiver. - 5 -
Transact SQL La procéduresp_add_alert permet de définir de nouvelles alertes liées soit à un numéro d erreur, soit à une gravité. Cette procédure doit être utilisée en étant positionné sur la base msdb. Activation/Désactivation de l alerte - 6 -
Cette opération se déroule par l intermédiaire de la procéduresp_update_alert. Suppression Il faut cette fois utiliser la procédure sp_delete_alert. d. En réponse à des erreurs utilisateur Il est possible de définir des messages propres à une application. Ces messages peuvent s ajouter aux messages déjà définis dans SQL Server. La gestion de ces messages se fait au travers de trois procédures stockées : sp_addmessage, sp_altermessage et sp_dropmessage pour créer, modifier ou supprimer un message. Par exemple, la procédure sp_addmessage est exécutée pour définir le message d erreur qui portera le n 50001, car tous les messages définis par l utilisateur portent un numéro supérieur à 50000. Lors de la définition du message, il faut également définir une gravité, une langue et un message d erreur. C est également à ce niveau qu il est possible de préciser si le message sera inscrit ou non dans le journal des évènements. - 7 -
Pour pouvoir définir le message en français, il est nécessaire de créer un message avec le même numéro d erreur mais en anglais. Pour déclencher l erreur à partir de l application de base de données, il suffit d exécuter la commande RAISERROR. La gestion des alertes utilise les mêmes méthodes que celles abordées lors de la gestion des alertes en réponse à des alertes SQL Server. e. En réponse à des seuils de performance Il est possible de définir des alertes sur des seuils de performance. Ces alertes sont liées aux compteurs SQL Server disponibles dans l analyseur de performances de Windows. Des alertes peuvent être créées sur les éléments suivants : méthode d accès, - 8 -
gestionnaire de tampon, gestionnaire de cache, base de données, verrou, statistiques SQL Server. Il n est pas nécessaire que l analyseur de performances soit exécuté sur le poste où est installé le serveur SQL. La définition des alertes est presque identique mais au lieu de lier l alerte à un numéro d erreur ou un niveau de gravité, l alerte est liée à un objet, un compteur, une instance (éventuellement) et une valeur au delà ou en deça de laquelle l alerte est levée (les compteurs SQL Server sont détaillés au chapitre Optimisation). Exemple : Définition à l aide de SQL Server Management Studio d une alerte sur un taux de remplissage du journal. Cette alerte notifiera un opérateur, afin que ce dernier réalise une sauvegarde puis tronque le journal. - 9 -