Surveiller les composants SQL Server

 

S’applique à : SQL Server 2016

La surveillance est importante car SQL Server fournit un service dans un environnement dynamique. Les données dans l'application sont fluctuantes. Le type d'accès requis par les utilisateurs peut changer. Le mode de connexion des utilisateurs change. Les types des applications accédant à SQL Server peuvent même changer, mais SQL Server gère automatiquement les ressources de niveau système, telles que la mémoire et l’espace disque, pour minimiser les paramétrages manuels nécessaires au niveau système. La surveillance permet aux administrateurs d'identifier les tendances de performances afin de déterminer si des modifications s'imposent.

Pour surveiller efficacement un composant SQL Server :

  1. Déterminer vos objectifs en matière de surveillance.

  2. Sélectionner l'outil approprié.

  3. Identifier les composants à surveiller.

  4. Sélectionner les éléments de mesure pour ces composants.

  5. Surveiller le serveur.

  6. Analyser les données.

Chacune de ces étapes est décrite ci-après.

Pour surveiller efficacement SQL Server, vous devez identifier clairement les motifs de surveillance. Ces motifs peuvent être les suivants :

  • Établir un niveau de référence des performances.

  • Identifier les fluctuations de performances dans le temps.

  • Diagnostiquer des problèmes de performances spécifiques.

  • Identifier les composants ou processus à optimiser.

  • Comparer les effets de différentes applications clientes sur les performances.

  • Auditer l'activité des utilisateurs.

  • Tester un serveur sous différentes charges.

  • Tester l'architecture d'une base de données.

  • Tester les programmes de maintenance.

  • Tester les plans de sauvegarde et de restauration.

  • Déterminer le moment où il convient de modifier votre configuration matérielle.

Une fois que vous avez identifié les motifs de la surveillance, vous devez sélectionner les outils correspondant à ce type de surveillance. Le système d'exploitation Windows et SQL Server comportent un jeu complet d'outils permettant de surveiller les serveurs dans des environnements riches en transactions. Ces outils révèlent clairement la condition d'une instance du moteur de base de données SQL Server ou d'une instance de SQL Server Analysis Services.

Windows fournit les outils suivants pour la surveillance d'applications s'exécutant sur un serveur :

  • Moniteur système, qui permet de collecter et d'afficher des données en temps réel sur des activités, telles que l'utilisation de la mémoire, du disque et du processeur ;

  • Journaux et alertes de performance ;

  • Gestionnaire des tâches

Pour plus d'informations sur les outils Windows ou Windows Server, consultez la documentation Windows.

SQL Server fournit les outils suivants pour la surveillance des composants de SQL Server :

  • Trace SQL

  • SQL Server Profiler

  • Distributed Replay Utility

  • SQL Server Management Studio Moniteur d'activité

  • SQL Server Management Studio Plan d'exécution de requêtes graphique

  • Procédures stockées

  • Commandes DBCC (Database Console Commands)

  • Fonctions intégrées

  • Indicateurs de trace

Pour plus d’informations sur les outils de surveillance de SQL Server, consultez Outils d’analyse et de paramétrage des performances.

La troisième étape dans la surveillance d'une instance de SQL Server consiste à identifier les composants à surveiller. Par exemple, si vous utilisez SQL Server Profiler pour tracer un serveur, vous définir la trace de sorte à collecter des données concernant des événements spécifiques. Vous pouvez également exclure des événements qui ne s'appliquent pas à votre situation.

Après l'identification des composants à surveiller, déterminez les éléments de mesure à utiliser pour la surveillance. Par exemple, après avoir sélectionné les événements à inclure dans une trace, vous pouvez choisir d'inclure uniquement des données spécifiques concernant ces événements. La limitation de la trace aux données pertinentes permet de réduire la quantité de ressources système requise pour effectuer le suivi.

Pour surveiller le serveur, exécutez l'outil de surveillance que vous avez configuré pour collecter des données. Par exemple, après avoir défini une trace, vous pouvez l’exécuter pour recueillir des données concernant les événements qui se sont produits sur le serveur.

Une fois le suivi terminé, analysez les données pour vérifier si vous avez atteint votre objectif de surveillance. Si ce n’est pas le cas, modifiez les composants ou les éléments de mesure utilisés pour surveiller le serveur.

Le processus de capture de données d’événement et de leur exploitation est décrit ci-dessous.

  1. Appliquer des filtres pour limiter les données d'événement recueillies.

    Le fait de limiter les données d'événement permet de s'attacher uniquement aux événements pertinents par rapport au scénario de surveillance en place. Par exemple, si vous souhaitez surveiller les requêtes lentes, vous pouvez utiliser un filtre afin de ne vous intéresser qu’aux requêtes dont l'exécution par l'application sur une base de données particulière prend plus de 30 secondes. Pour plus d’informations, consultez Définir un filtre de trace (Transact-SQL) et Filtrer des événements dans une trace (SQL Server Profiler).

  2. Surveiller (capturer) les événements.

    Dès qu'elle est activée, la surveillance active capture des données à partir de l'application, de l'instance de SQL Server ou du système d'exploitation spécifié. Par exemple, lorsque l'activité du disque est analysée à l'aide du Moniteur système, ce dernier capture les données d'événement, notamment les lectures et les écritures sur le disque et les affiche sur l'écran. Pour plus d’informations, consultez Analyser l’utilisation des ressources (Moniteur système).

  3. Enregistrer les données d'événement capturées.

    L'enregistrement des données d'événement capturées vous permet de les analyser ultérieurement, voire de les relire avec Distributed Replay Utility ou le SQL Server Profiler. Les données d'événement capturées sont enregistrées dans un fichier pouvant être rechargé dans l'outil qui l'a créé à l'origine pour analyse. SQL Server Profiler permet d’enregistrer les données d’événement dans une table SQL Server. L'enregistrement des données d'événement capturées est essentiel lors de la création d'un niveau de référence des performances. Les données du niveau de référence des performances sont enregistrées et utilisées lors de la comparaison des données d'événement récemment capturées afin de déterminer si les performances sont optimales. Pour plus d’informations, consultez Modèles et autorisations du générateur de SQL Server Profiler.

  4. Créer des modèles de trace contenant les paramètres spécifiés pour capturer les événements.

    Ces modèles contiennent des spécifications concernant les événements proprement dits, les données d’événement et les filtres utilisés pour la capture de données. Ils permettent de surveiller ultérieurement un ensemble spécifique d'événements sans avoir à redéfinir les événements, les données d'événement et les filtres. Par exemple, si vous voulez souvent surveiller le nombre d'interblocages et les utilisateurs impliqués dans ces interblocages, vous pouvez créer un fichier définissant ces événements, données d'événement et filtres d'événement, puis enregistrer le modèle et appliquer le filtre la prochaine fois que vous voudrez surveiller les interblocages. SQL Server Profiler utilise les modèles de trace à cet effet. Pour plus d’informations, consultez Définir les valeurs par défaut des définitions de trace (SQL Server Profiler) et Créer un modèle de trace (SQL Server Profiler).

  5. Analyser les données d'événement capturées.

    Les données d'événement capturées sont chargées dans l'application qui les a capturées afin d’être analysées. Par exemple, une trace capturée à partir de SQL Server Profiler peut être rechargée dans SQL Server Profiler à des fins de consultation et d’analyse. Pour plus d’informations, consultez Afficher et analyser des traces avec SQL Server Profiler.

    L'analyse des données d'événement implique l'identification des événements et de leur cause. Ces informations vous permettent d'effectuer des modifications susceptibles d'améliorer les performances, telles que l'ajout de mémoire, la modification d'index, la correction de problèmes de code avec des procédures stockées et des instructions Transact-SQL, en fonction du type d'analyse effectuée. Par exemple, vous pouvez utiliser l'Assistant Paramétrage du Moteur de base de données pour analyser une trace capturée depuis SQL Server Profiler et créer des recommandations d'index en fonction des résultats.

  6. Relire les données d'événement capturées.

    La relecture d'événements permet d'établir une copie de test de l'environnement de base de données à partir duquel les données ont été capturées, puis de répéter les événements capturés tels qu'ils se sont initialement produits sur le système réel. Cette fonction n'est disponible qu'avec Distributed Replay Utility ou le SQL Server Profiler. Ces événements peuvent être relus à la vitesse à laquelle ils se sont produits, aussi rapidement que possible (pour contraindre le système) ou, plus vraisemblablement, pas à pas (pour analyser le système après chaque événement). L'analyse des événements exacts dans un environnement de test empêche tout effet nuisible sur le système de production. Pour plus d’informations, consultez Relire des traces.

Ajouts de la communauté

AJOUTER
Afficher: