Dans un article précédent sur l'outil de surveillance Foglight pour les bases de données, nous avons parlé
des capacités de surveillance à partir d'une seule interface: SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra et MongoDB. Aujourd'hui, nous analyserons les approches permettant d'identifier rapidement les causes d'un fonctionnement anormal de Microsoft SQL Server:
- Rechercher une source de verrouillage;
- Comparaison des paramètres de la base de données «était-ce-devenu» avec référence aux mesures de performance;
- Recherchez les changements dans la structure de la base de données, en raison desquels les performances ont diminué.
Détails sous la coupe.
Foglight for Databases est un outil de surveillance des performances et des changements dans les bases de données populaires. Si vous n'êtes pas familier avec ce produit, nous vous recommandons de lire l'
article précédent . Et ci-dessous, nous avons donné des captures d'écran de l'interface pour démontrer les capacités de Foglight et la facilité de trouver des problèmes dans la base de données.
Verrouiller la recherche de source
Vous pouvez rechercher la raison des verrous dans Management Studio. Mais un poste de travail avec cet utilitaire peut ne pas être à portée de main, et l'ouverture de la console n'est pas toujours pratique. Dans Quest Foglight, vous pouvez trouver la raison du blocage en quelques clics. Dans la capture d'écran ci-dessous, vous voyez la console principale de surveillance de la base de données.
Un administrateur de garde qui a déjà reçu une notification accède à la vue SQL PI (Performance Investigator). La colonne Workload a un champ rouge visible, qui indique une valeur non nulle du paramètre Lock Wait.
Après avoir cliqué sur le graphique Workload, une vue détaillée des sources de chargement de la base de données s'ouvre et dans la colonne de gauche du menu pour l'analyse des performances multivariées. Ici, comme dans la capture d'écran ci-dessus, on peut voir que le blocage entraîne une grande utilisation des ressources. Dans le menu de gauche, il y a une vue spéciale des objets verrouillés, dans laquelle un objet verrouillé est détecté.
Les objets verrouillés stockent les objets verrouillés. Sur le côté droit de l'écran, les raisons du blocage: durée, à partir de quel serveur (ou poste de travail), quel programme, à partir de quel utilisateur et objet exécutable ayant conduit au blocage.
Lorsque vous basculez vers un objet exécutable, une nouvelle vue s'ouvre avec la possibilité d'afficher le contenu de cet objet. Et après avoir cliqué sur View Batch Text, le code exécuté s'ouvrira.
Accélérer le temps de diagnostic est la clé du succès de l'équipe informatique.
La comparaison des paramètres de la base de données était devenue
Les modifications apportées par les développeurs ou les administrateurs de base de données peuvent également entraîner des ralentissements spectaculaires. Mais au moment du problème, peu importe qui l'a fait, il est important de savoir ce qui s'est passé. Nous allons essayer de comprendre cela. Ouvrez le menu contextuel de l'instance de base de données de problème.
Dans le menu qui s'ouvre, accédez à SQL PI (Performance Investigator) pour ouvrir la vue avec une analyse multivariée.
Passons à la vue Baseline pour évaluer le comportement d'une métrique par rapport à ses valeurs habituelles.
Le graphique montre qu'après 13 h 40, une augmentation anormale de la consommation des ressources a commencé.
Dans cette vue, nous allons configurer avec quoi comparer. Considérons maintenant la comparaison de la métrique avec elle-même (le long de la ligne de base), car Déviation anormale révélée ci-dessus. En général, vous pouvez également comparer les performances avec une autre instance de base de données.
Après avoir sélectionné les objets à comparer, le précieux bouton Comparer apparaît.
La vue moyenne montre que des valeurs anormales ont été observées par les métriques: temps actif, exécutions et taux de connexion. Commençons une nouvelle comparaison pour identifier les changements.
Comparez les valeurs des métriques avec nous-mêmes, mais il y a un jour.
Après avoir sélectionné les paramètres, le bouton Comparer apparaît, sur lequel vous devez cliquer.
Une vue apparaît sur laquelle il y a des mesures à comparer. Pour une démonstration, nous sélectionnerons l'élément de menu Programmes. La section Statistiques montre déjà une double augmentation de la valeur de la mesure Exécutions.
À gauche et à droite de l'échelle, dans la section du menu Programmes, les valeurs métriques sont affichées. Nous voyons ici que le temps actif et les exécutions ont presque doublé, et c'est l'occasion d'une analyse détaillée de la situation.
De la même manière, vous pouvez effectuer une analyse comparative d'autres mesures et télécharger n'importe quelle présentation dans un rapport PDF.
Rechercher des changements dans la structure de la base de données
Les modifications apportées aux index, aux plans d'exécution et à d'autres objets peuvent ne pas être documentées. Le développeur ou l'administrateur de la base de données apporte des modifications apparemment mineures, qu'il peut oublier après un certain temps. Dans l'interface Foglight pour les bases de données, les modifications de configuration sont liées aux modifications de performances. Pour identifier les modifications, passez de l'écran principal de surveillance de la base de données à la vue Workload.
Supposons que nous savons qu'une charge importante sur la base de données est générée à partir d'une machine cliente. Nous révélons les ordinateurs clients dans la vue de gauche.
Les lots sont triés en fonction de la charge sur la base de données. Allons au premier objet de la liste, puis voyons les modifications (Change Tracking).
Sur le graphique, selon la légende de droite, les changements correspondants pour la période sélectionnée sont marqués. Le premier changement ici est la suppression de l'index, le second est l'ajout d'un nouveau plan d'exécution. Comme vous pouvez le voir, après la suppression de l'index, la charge Autre attente a fortement augmenté - la zone violette (l'exécution de travaux par lots s'y réfère également). Le quatrième changement est une augmentation du niveau de parallélisme, qui a potentiellement conduit à une augmentation du nombre de requêtes (IO Wait - zone bleue). Considérez les implications de l'ajout d'un nouveau plan d'exécution.
Après la transition, les détails du nouveau plan d'exécution se sont ouverts. Comparez maintenant les changements qui se sont produits.
Après la transition, les détails du nouveau plan d'exécution se sont ouverts.
Le même plan d'exécution peut être ouvert dans Management Studio directement à partir de l'interface Quest Foglight.
Il regarde donc dans la console Management Studio.
Lorsque vous passez à la vue Historique, vous pouvez voir les modifications des mesures au fil du temps.
La vue Historique peut être utilisée pour évaluer l'impact des modifications sur une métrique particulière. Ensuite, accédez à la vue Autre.
Dans cette vue, vous pouvez voir quels lots ont affecté la charge de la base de données. Ils sont déjà triés par ordre décroissant.
En plus de suivre automatiquement les modifications, un utilisateur Foglight peut ajouter des modifications manuellement. En cas de dégradation des performances, l'administrateur en service ne recherchera plus la cause de la dégradation du service.
Si vous avez aimé Foglight pour bases de données et que vous souhaitez l'essayer sur vos bases de données - laissez une demande de distributions et de clé d'essai
dans le formulaire de commentaires sur notre site Web. Fonctionnement stable de la base de données et localisation rapide des travaux anormaux!