SQL Server 2016 : Diagnostic

Analyser les attentes des entrées et sorties

Testez gratuitement nos 1271 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Des types d'attente donnent des indications sur les lenteurs des disques. Voyez comment y adjoindre une vue de gestion dynamique spécifique pour en faire une analyse précise.
06:24

Transcription

Pour cette vidéo j'ai repris, la requête de Paul Randal. Et j'observe un serveur ici qui a démarré depuis très peu de temps. Donc ce n'est pas très intéressant. Et c'est pour reprendre quelque chose qui correspond un peu à la réalité. On a brièvement abordé les IO PAGEIOLATCH_SH, c'est quelque chose que vous allez voir souvent. PAGEIOLATCH en tout cas. C'est un des types d'attente les plus fréquents, parce que, eh bien, on a toujours des latences une petit peu sur le disque. Il y a toujours quelque chose au niveau du disque. Ici, ce que ça nous dit, c'est qu’on travaille sur des pages. Donc, page du moteur de stockage de 8k. On travaille en IO, donc vraiment en Entrée/Sortie physique. On travaille donc sur le disque. Et puis, on maintient un LACTH, qui est de type CHERD. Le LATCH, c'est un verrou. Mais pas un LOCK, comme ici. Le LATCH, c'est un verrou qui n'est pas un verrou logique. C'est-à-dire que ce n'est pas un verrou de protection dans une transaction d'une ligne ou d'une page ou d'une table. C'est un verrou physique sur la page, qui est maintenu par le moteur de stockage pour empêcher qu'on puisse travailler en même temps sur cette page. SHARED, ça veut dire qu'on est en train de la lire. Si on fait un PAGEIOLATCH on maintient un verrou pendant qu'on est en train de lire une page. Quand je dis on, c'est bien sûr le moteur de stockage. Quand le moteur de stockage est en train de lire une page, que ce soit sur le disque pour pouvoir la monter en mémoire, la monter en RAM dans le buffer. Si vous avez des attentes régulières et prolongées en PAGEIOLATCH, eh bien, regardez où en est votre disque. Normalement c'est quelque chose que vous allez corréler avec des compteurs de disque spécifiques. Je vais vous parler un peu plus tard du perfmon, du moniteur de performance Windows, dans lequel on va voir quelques informations sur le disque. Mais, vous avez aussi une autre vue de gestion dynamique, à l'intérieur de SQL serveur, qui peut vous aidez à identifier ce genre de problème. Elle s'appelle, donc toujours sys.dm_ io_virtual_file_stats. Ce n'est pas une vue d'ailleurs, c'est une fonction. Vous voyez que, c'est bien une fonction qui retourne une table. Et on peut lui passer en paramètre, l'ID de la base de données et un ID de fichiers. Donc je vais analyser à l'aide de la fonction db_id, à laquelle je passe le nom de ma base de données. Je vais analyser quelles sont les statistiques d'Entrée/Sortie. Donc, on a io_virtual_file_stats, les statistiques fichiers par fichiers d'entrée sortie, des fichiers de ma base de données. Alors, j'ai oublié de mettre le numéro du fichier. Comme je les veux tous, je vais mettre un nul. Et voilà quelques informations intéressantes. Ça se passe comme ceci. J'ai un ID de fichier qui est ici. Cet ID de fichier correspond à en général, un, le fichier de données, deux, le fichier de journal de transaction. Et si vous avez créé d'autres fichiers, que ce soit d'autres fichiers de données ou d'autres fichiers de journal, eh bien, vous aurez plus de lignes évidemment. Vous avez le nombre de millisecondes, de sampling, c'est-à-dire de récupération de statistiques qui sont affichées. Ça veut donc dire que les statistiques qui suivent ont été récupérés pendant sept périodes de temps en millisecondes. Combien pendant cette période on a fait de reads ? C'est-à-dire, combien d'opérations d'IO en lecture ? Combien on a fait de writes ? Donc d'opérations d'IO en écritures ? Et puis, combien est-ce qu'on a lu d'octets ? Donc, même chose en écriture. Combien est-ce qu'on a écrit d'octets ? Bon bref, vous me suivez. Et combien on a eu de millisecondes de stall ? C'est-à-dire d'attente, de ralentissement ? D'attente finalement où on n’a pas pu lire aussi vite qu'on le voulait, de la latence, si vous voulez. Donc c'est très intéressant, parce que par rapport au nombre de reads, eh bien, on peut mesurer le nombre de millisecondes de latence, par écriture. Et ici on se retrouve avec un total des deux, c'est-à-dire un total de ça et de ça. Donc vous vous imaginez que tout ceci est très utile. Parce que je peux regarder maintenant. J'ai 234, opération de lecture, et ça a duré 1300 millisecondes. Donc une moyenne de cinq ou six millisecondes par lecture. Ça va, c'est très raisonnable. Mais imaginez qu'on calcul des latences de 20 millisecondes, 25 millisecondes par opération de lecture, c'est quand même le signe que le disque n'est pas aussi optimal, ou disons qu'on utilise beaucoup le disque. Peut-être qu'il est saturé ou peut-être que le disque lui-même n'est pas de bonne qualité ou il pourrait être plus rapide. Bref, la machine peut-être ne suit pas. Et grâce à cette fonction, eh bien, on peut le voir, fichier par fichier. Ce qui est intéressant c'est que, si vous récupérez les informations de ce fichier, vous voyez sur quel disque il se trouve et finalement vous pouvez faire une analyse en disant, tous les fichiers qui sont sur ce même disque montre qu'il y a une forte latence par exemple en lecture. Ça voudrait dire que ce disque est saturé, et ça veut dire que je peux songer à peut-être répartir mes fichiers différemment. Prendre le fichier qui est le plus saturé ici et le poser sur un disque différent, de façon à désengorger ce disque. Quelque chose qui va être très classique, ça va être tempdb. Si vous analysez tempdb, ici j'ai plusieurs fichiers parce que c'est une recommandation Microsoft d'avoir autant de fichiers que de sockets de façon à pouvoir paralléliser un peu les IO en terme de thread. Donc ça c'est une parenthèse. Ici, j'ai donc plusieurs fichiers. Si je m’aperçois que j'ai quand même beaucoup de latence sur tempdb, aussi bien sur les fichiers de données qui sont ceux-ci, que sur le fichier de journal de transaction. En général, le fichier de journal de transaction est plutôt en écriture, sur la latence. Parce que, le fichier de journal écrit beaucoup. Eh bien, dans ce cas-là, je peux vraiment identifier le besoin de déplacer tempdb ou certains fichiers de tempdb, sur un disque différent, de façon à désengorger mon disque. Vous voyez que, en regardant d'abord les attentes, en vous apercevant que vous avez des attentes en terme d'Entrée/Sortie d'IO. Ensuite, en regardant à l'aide de cette fonction, quel fichier réellement provoque ces attentes, vous avez un excellent moyen d'améliorer les performances en Entrée-Sortie de votre base de données.

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 !