SQL Server : Utilisation des objets de gestion dynamique
Les objets de gestion dynamique vous permettent de gérer et de surveiller en détail la charge de travail dans SQL Server, ce qui est essentiel pour l’optimisation des performances.
Extrait de l'ouvrage « SQL Server DMV Starter Pack », publié par Red porte livres (2010).
Glenn Berry, Louis Davidson et Tim Ford
Dynamic Management Objects (DMO) sont un ensemble d'objets SQL Server stocké dans le schéma du système. Ils vous permettent d'une fenêtre dans les activités en cours d'exécution sur votre différentes instances de SQL Server et les ressources qui consomment ces activités.
En d'autres termes, DMOs exposent des informations utiles concernant les connexions, les sessions, les transactions, les instructions SQL et les processus qui s'exécutent sur une instance de la base de données, la charge de travail qui en résulte généré sur le serveur, comment il est distribué, dans le cas où les points de pression sont et ainsi de suite. Ayant a révélé un goulot d'étranglement particulier ou un point de pression, vous pouvez alors prendre les mesures appropriées pour corriger le problème — peut-être ajouter un index en réglant une requête, ou simplement une session de blocage de mise à mort.
Le terme « dynamique » fait référence au fait que les informations stockées dans DMOs générées dynamiquement à partir d'un large éventail de points d'instrumentation. Il s'agit des structures en mémoire tout au long du moteur SQL Server. Ces données sont ensuite exposées sous forme de tableau dans le schéma de base de données sys. Les données sont exposées dans les affichages, auquel cas ils sont désignés comme des vues de gestion dynamique (DMV), soit dans les fonctions de valeurs de la table, auquel cas ils sont désignés comme des fonctions de gestion dynamique (DMF).
DMV et DMF est essentiellement les vues système et les fonctions du système. Utilisez-les comme vous utiliseriez n'importe quel affichage et la fonction au sein de SQL Server : les requêtes, rejoindre, passage de paramètres et finalement retournant un résultat unique défini contenant les données que vous deviez rechercher un problème spécifique concernant l'état ou la santé de votre instance de SQL Server.
Performance Tuning with DMV
DMOs exposent un tableau dizzying parfois des informations. La vue système sysprocesses d'origine a essentiellement été dénormaliser et nombreux DMOs nouvelles ont été ajoutés. De nombreuses nouvelles colonnes de données sont désormais disponibles pour l'interrogation. Le moteur de base de données devient mieux instrumenté, la quantité de données disponibles sur le moteur et le travail qu'il effectue, continuera à croître.
La complexité d'assembler des données d'un tableau disparates de DMOs, couplé avec les choix de colonnes seront initialement troublantes où exposées, a poussé certains administrateurs d'apparente interrogeant DMOs collecte sorts mystic.
Toutefois, le processus de la dénormalisation a, de nombreuses manières, rendu DMOs renvoient beaucoup plus faciles à analyser et comprendre les données. Une fois que vous commencez à écrire vos propres scripts, vous verrez les astuces de mêmes et les motifs de jointure similaires, temps et encore utilisés. En tant que tel, un ensemble relativement restreint de scripts peut être facilement adapté pour l'adapter à nombreuses exigences.
Dans une certaine mesure, parcourt DMOs pour les données de diagnostic vous avez besoin d'un processus de pelage couches arrière. Dans la couche externe, nous pouvons trouver qui est connecté à nos instances SQL Server et comment ils sont connectés ; les sessions sont exécutés contre eux ; et les requêtes sont exécutées par ces sessions. Nous pouvons trouver les détails des instructions SQL exécutées par ces demandes, les plans de requête sont utilisés pour les exécuter et ainsi de suite.
En descendant d'un calque, nous avons le niveau de la transaction, dans le cas où nous pouvons déterminer quels verrous sont maintenus à la suite de ces transactions, étudier les éventuelles de blocage et ainsi de suite. Déplacement d'une autre couche de duvet, nous pouvons trouver comment la charge représentée par les demandes soumises se traduit par un travail réel dans le système d'exploitation. Nous pouvons déterminer, par exemple :
- Quelles sont les tâches réelles (threads) sont en cours d'exécution afin de répondre aux demandes
- Quel travail leurs performances en termes d'utilisation d'e/S, le processeur et mémoire
- Comment les e/S est réparti entre les différents fichiers
- Comment les threads long passent en attente, Impossible de continuer et pourquoi
Votre travail consiste à assembler tous les éléments de données à partir de différentes couches de fournir les résultats nécessaires pour mettre en évidence les problèmes spécifiques dans le système.
Point de temps vs. Cumulative
Comme mentionné, nous pouvons rechercher les données stockées sur DMOs juste comme nous le ferions une autre table, afficher ou de la fonction. Cependant, n'oubliez pas que les données que vous voyez sont « dynamiques » dans la nature. Il est collecté à partir d'une plage de différentes structures dans le moteur de base de données et représente un point-à-temps « instantané » de l'activité qui était en cours sur votre serveur au moment où que vous avez exécuté la requête DMO.
Parfois, c'est exactement ce que vous voulez. Vous avez une performance de délivrer et de découvrir ce que les requêtes sont exécutées sur le serveur peut être dû à elle. Parfois, cependant, il peut s'avérer assez difficile interroger les données dans ces DMOs point-à-temps dans l'espoir que le problème sera simplement « ressortir. »
Si, par exemple, vous avez un problème de performances et recherchez tout « » verrouillage inhabituelles, puis il est peu probable qu'un « select [colonnes] de [verrouiller DMV] » vous indiquera la plupart, sauf si vous êtes familiarisé avec le verrouillage « normal » ressemble à sur votre système et vous pouvez repérer facilement les anomalies.
N'oubliez pas que les données de point-à-temps et probablement va changer chaque fois que vous interroger, comme l'état du serveur change. Vous devriez voir parfois des résultats anormaux ou non représentatifs, et vous devrez peut-être exécuter un script plusieurs fois pour obtenir une image exacte de l'activité sur votre instance.
Dans les autres cas, DMOs sont cumulatives. En d'autres termes, les données dans une colonne donnée sont cumulées et incrémentée chaque fois qu'un certain événement survient. Par exemple, chaque fois qu'une session attend un certain temps pour une ressource soit disponible, cela est enregistré dans une colonne de la DMV sys.dm_os_wait_stats. Passé lorsque vous interrogez une DMV vous le verrez, par exemple, le montant total du temps à attendre pour diverses ressources, dans toutes les sessions, étant donné que SQL Server a été démarré ou redémarré — à moins qu'une vérification de cohérence de base de données ou DBCC, commande a été exécutée pour effacer manuellement les statistiques stockées.
Alors que cela vous donnera une vue d'ensemble d'où le temps a été passé en attente sur une longue période, il rend difficile de voir les petits détails. Si vous souhaitez mesurer l'impact de la modification à la base de données (un nouvel index, par exemple), vous devrez prendre une mesure de référence, modifier et puis mesurer la différence.
Enfin, toujours garder à l'esprit que la majeure partie des données que vous voyez dans ces DMOs est agréger des données rassemblées auprès d'autant de sessions, de nombreuses demandes et de transactions. Le wait_stats mentionnées précédemment DMV, par exemple, vous montrera à une instance au niveau où SQL Server passé à temps d'attente, regroupées sur toutes les sessions. Vous ne pouvez pas suivre les temps d'attente au niveau de session individuelle, à moins que, bien entendu, vous travaillez sur un serveur isolé.
.png)
.png)
.png)
Glenn Berry travaille comme architecte de base de données chez Technologies NewsGator dans Denver, Colo. Il est MVP SQL Server et possède une collection entière de certifications de Microsoft, y compris MCITP, MCDBA, MCSE, MCSD, MCAD et MCTS, ce qui prouve qu'il aime prendre des tests.
Louis Davidson a été dans le secteur informatique pendant 16 ans en tant que développeur de base de données d'entreprise et architecte. Il a été SQL Server Microsoft MVP pour six ans et a écrit quatre livres sur la conception de base de données. Il est actuellement architecte de données et parfois DBA pour le réseau de diffusion Christian, prise en charge des bureaux dans Virginia Beach, en Virginie et Nashville, Tennessee
Grégory Ford est MVP SQL Server et a travaillé avec SQL Server pour plus de 10 ans. Il est le principal DBA et l'expert pour la plate-forme de SQL Server pour la santé du spectre. Il a été écrit sur la technologie depuis 2007 pour une variété de sites Web et gère son propre blog à thesqlagentman.com, couvrant le SQL les rubriques de développement bien comme télétravail et professionnelle.
En savoir plus sur « SQL Server DMV Starter Pack » au red-gate.com/our-company/about/book-store.