Le 14 septembre 2017, nous avons publié une version actualisée de notre Politique de confidentialité. En utilisant video2brain.com vous vous engagez à respecter ces documents mis à jour. Veuillez donc prendre quelques minutes pour les consulter.

SQL Server 2016 : Diagnostic

Découvrir les évènements étendus

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Partez à la découverte des évènements étendus. Exploitez-les pour obtenir des informations de diagnostic très précises.
08:21

Transcription

Dans SQL serveur, vous avez, depuis plusieurs versions, un autre outil de diagnostic, qui remplace le profiler ou SQL trace, qui sont des fonctionnalités maintenant dépréciées dans SQL serveur. Je ne vais pas parler ici du profiler ou du SQL trace, c'est quelque chose qui a été évoqué dans une formation qui est dans le catalogue, sur l'optimisation des requêtes, c'est un outil de trace qui permet de regarder tout ce qui se passe sur un serveur SQL simplement. Mais il est remplacé, petit à petit, par ce qui s'appelle les « évènement étendus », ou extended events, qu'on trouve ici, dans management studio, « évènement étendus », et qui est, on peut dire, un framework de trace plus évolué et plus performant. Donc, je vais juste vous en parler, sachez que ici, dans management studio, vous avez cet interface graphique, qui va vous permettre de générer ces évènements étendus pour SQL serveur 2012 ou ultérieur. Pour voir ici ce dossier, il faut être au moins dans SQL serveur 2012. Les évènements étendus existent depuis SQL serveur 2008, en 2008 R2 et en 2012, ils ont quand même pas mal changé, donc, vous avez pas mal de modifications qui ont été faites et on va dire que ça s'est stabilisé à partir de 2012. En 2008 et en 2008 R2, vous n'avez pas d'interface graphique, disponible dans management studio, il faudra donc écrire des requêtes de création de sessions d'évènements étendus à la main, ou bien utiliser un add-in, donc un ajout, un plug-in on pourrait dire, pour management studio que vous trouvez sur le site codeplex, ça, c'était entre parenthèses. On va partir du principe que vous êtes au moins en 2012, vous avez cet environnement d'évènements étendus, et je vais vous montrer l'intérêt de ces évènements étendus, notamment, par rapport aux attentes. On avait vu comment voir les attentes en cours, on a vu comment voir des statistiques d'attente, mais serait-il possible de suivre sur une session, sur une requête même, quelles sont les attentes générées par cette session et par cette requête? Donc, pour ça, j'ai préparé une requête très simple: je vais dans PachaDataFormation, j'utilise ici une commande DBCC qui s'appelle DropCleanBuffers, et, quand vous voyez Buffer, vous avez compris qu'on parle du cache de données. C'est donc une requête qui va vider le cache de données, et ensuite, je fais un simple Select étoile From Contact Contact, donc, théoriquement, déjà, puisque je n'ai plus rien dans le Buffer, je devrais avoir des opérations de lecture directement sur le disque, au moins ça ! Alors, je vais essayer de le suivre avec des évènements étendus, Je rentre, je vais dans les sessions, je clique et j'ai deux façons de créer un évènement étendu, soit, un assistant relativement simplifié, soit, une nouvelle session avec un environnement un petit peu plus compliqué. Je vais prendre juste l'assistant, ça nous suffira pour l'instant. Je vais donner un nom de ma session, par exemple, « attente », et puis, je vais choisir ou non, d'utiliser un modèle, c.à.d, une session déjà pré-définie, sur laquelle je peux me baser. Je ne vais pas utiliser de modèle, on va faire ça à la main, et on va se retrouver devant une interface peut-être un peu compliquée, mais on a ici nos évènements, qui correspondent pour certains à des évènements qu'on a l'habitude de voir dans le profiler, et puis, on en a beaucoup d'autres. Elles sont classées, car, les évènements étendus proviennent conceptuellement d'un outil ou d'un framework de trace dans Windows qui s'appelle : Event Tracing for Windows, ETW, et dans ETW, on a des catégories et des canaux, alors ici, on a aussi des catégories et des canaux, c'est pas très éclairant, en tout cas, les canaux, ce n'est pas particulièrement éclairant, mais, on va se concentrer sur nos évènements à récupérer dans notre session. Et puis, on peut ici très simplement filtrer, donc, on va surtout filtrer. Je vais dire : je voudrais récupérer... le batch completed, ça veut dire qu'on a terminé finalement, l'exécution d'un batch de requête. Donc, je vais le récupérer. Je vais aussi prendre wait, donc, les attentes, et je vais voir que j'ai un wait info, éventuellement, un wait info external pour des infos sur des attentes qui sont données, si vous voulez, à Windows, c'est plutôt Windows qui nous dit : Je suis en train d'attendre sur quelque chose. Je ne vais garder que wait info, ça nous suffira amplement. Si vous avez l'habitude du profiler, vous voyez déjà une petite différence, c'est que je n'ai pas un tableau avec des colonnes qui me permet de sélectionner les colonnes que je veux récupérer pour chaque évènement. Parce-que chaque évènement a des champs qui sont ici, d'évènements différents. Ces champs d'évènements appartiennent uniquement à un évènement. C'est logique ! Ces évènements finalement sont des choses totalement différentes, chacun a ses propres champs et, dans l'ancienne version dans SQL trace, eh bien, on avait des champs pré-définis, mais, c'était bête, parce-que on avait des champs comme integer1, integer2, pour dire, si on a des chiffres à, montrer, on va tout mettre dans integer1, quels que soient les évènements. Ici, chaque évènement a ses propres champs donc, c'est beaucoup plus clean. Je vais prendre wait info... comme ceci... et, on va dire pour l'instant ça me suffit et je continue... je récupère seulement deux évènements... je vais sur suivant et je vais récupérer ici, je vous montre juste... des champs globaux, qu'on appelle également des actions. Historiquement, ça s'appelle des actions parce qu'il y a certains de ces champs qui peuvent déclencher une action. Mais pensez-y vraiment comme des champs globaux qu'on va ajouter aux informations des champs de chaque évènement. Si je récupère un évènement wait info, comme on l'a vu, il a ses quelques champs à lui, mais j'ai peut-être besoin d'informations supplémentaires, par exemple, quelle est l'identifiant de la session dans lequelle il s'est exécuté. Quelle était la requête sur laquelle il s'est exécuté. Quel est le processeur sur lequel il s'exécute. Quelle est la base de données dans le contexte de laquelle ça s'exécute. Et vous avez toutes ces informations ici, donc, je vais pouvoir sélectionner, par exemple, le SQL texte, qui va être le texte de la requête sur laquelle l'attente va se générer, et ça, c'est très intéressant. Donc, je récupère les champs globaux qui m'intéressent. Voyez par exemple, j'ai le session ID, qui va correspondre à l'ID de ma session. Par exemple, ici, je sais que je vais exécuter ceci et que ça va être l'ID 56 que je vois ici, que je vois ici également, l'ID 56. Ok, je garde ça en tête, donc, je n'ai pas besoin de le récupérer, ce qui m'intéresse surtout, c'est le texte de la requête ici. Ensuite, je vais pouvoir appliquer des filtres. Donc, bien entendu, je vais pouvoir filtrer les évènements, ce qui est intéressant, c'est que le filtre est beaucoup plus performant que dans le profiler, parce que, selon le type de filtre, par exemple, si je filtre sur un champ qui appartient à un évènement mais qui n'est pas un champ global, pas une action, et bien le filtre va pouvoir filtrer directement, en amont, à la génération même de l'évènement, ça va être beaucoup plus rapide. Je vais prendre un champs et dire que le champs global qui s'appelle session ID doit être égal à 56, je ne vais finalement récupérer que des informations de la session 56. Je vais sur suivant et je vais dire maintenant, comment est-ce qu'on va collecter ? Une session d'évènements peut avoir plusieurs cibles, il y a deux cibles assez classiques, qui sont, une zone en mémoire qu'on appelle le ring buffer et qui a été traduit ici, assez mal, il faut l'admettre par "cible mémoire tampon en anneau". Pensez simplement à une zone en mémoire qui agit comme une pile d'informations, dans laquelle on va pouvoir, si je coche ceci, garder seulement, par exemple, les 1000 derniers évènements, juste en mémoire. Donc, ça va être très rapide, vous pouvez aussi, alors, c'est « et » et « ou », vous pouvez avoir plusieurs cibles en même temps, et vous pouvez choisir plutôt un fichier sur le disque, sur le disque du serveur, bien sûr et/ou une zone en mémoire. Donc ici, on va plutôt prendre une zone en mémoire, et lorsque je fais suivant, j'ai tout ce qui faut pour créer ma session d'évènements.

SQL Server 2016 : Diagnostic

Prenez en main les outils de diagnostic intégrés à SQL Server. Soyez en mesure de comprendre et d'analyser les problèmes de performance rencontrés le plus fréquemment.

1h58 (20 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :14 déc. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !