SQL Server 2016 : Diagnostic

Analyser avant de conclure

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Vous aborderez le sujet délicat de l'interprétation des signes. Vous apprendrez également à ne pas faire de conclusions hâtives.
04:19

Transcription

Concluons ce chapitre dédié aux attentes et à leurs intérêts dans SQL Server pour diagnostiquer ce qui se passe mal. Je voulais quand même vous dire de faire attention : ne sautez pas sur les conclusions. On a vu qu'on avait des attentes sur les I/Os. On a vu qu'on avait SOS_SCHEDULER_YIELD, donc on pourrait dire des attentes sur des requêtes qui prennent du temps et peut-être des processeurs surchargés. Mais si vous avez des attentes sur des I/Os, par exemple ici, le disque. Est-ce que ça veut dire que le disque est lent ? Est-ce que ça veut dire qu'il faut acheter un nouveau disque ? Non ! Pas forcément. Parce que, quels peuvent être les mécanismes ? Une requête qui n'a pas d'index pour s'exécuter va parcourir beaucoup plus de données, donc elle va avoir besoin de beaucoup plus de pages de données et peut-être qu'elle va sur-utiliser le disque. Il n'y a pas assez de RAM peut-être pour contenir toutes les pages et il faut relire régulièrement sur le disque. Alors est-ce que ça veut dire à ce moment-là que c'est pas le disque le problème, mais la RAM ? Il n'y aurait pas assez de RAM pour avoir un buffer, un cache de données suffisant pour maintenir toutes les pages et donc on travaillerait trop avec le disque. Oui, peut-être qu'effectivement, si on rajoute de la RAM, on aura moins de problèmes de disque. Donc la première réaction qui serait de dire : « le disque est surchargé, donc changeons de disque, » n'est pas une bonne réaction. En tout cas, à priori, il faut aller chercher plus loin. Est-ce qu'en ajoutant de la RAM, on va travailler moins avec le disque, donc le libérer et avoir beaucoup moins de problèmes ? OK, peut-être. Donc on rajoute de la RAM ? Eh bien, pas forcément. Si, une fois de plus, je n'ai pas d'index, je vais devoir peut-être parcourir l'intégralité d'une table pour faire une petite recherche. A ce moment-là, je vais devoir placer toute la table dans le buffer en RAM et la parcourir. Est-ce que vraiment il faudrait que je rajoute de la RAM ou que je crée un index ? Evidemment il faudrait que je crée un index ! Vous voyez qu'il y a toujours une chaîne finalement de causalité et qu'il est important de remonter à la chaîne. Je vous ai dessiné ici le disque, une base de données. Donc on pourrait se dire la configuration de la base de données ne correspond pas, ça pourrait être de la RAM, est-ce qu'il faut plus de RAM ? Et souvent dans cette première partie ici, dans cette zone, qui est la zone, on va dire du matériel, c'est souvent la zone dans laquelle on a tendance à réfléchir au premier niveau en disant : « Voilà, la machine à l'air d'être vraiment surchargée, il faut en acheter une autre ; il faut rajouter de la RAM. » Mais non ! Qu'est-ce qu'on fait dans un moteur de base de données relationnelles ? On pense d'abord à l'optimisation. Ceci, c'est souvent des signes qu'on a des problèmes au niveau de deux ou trois choses. En fait, trois choses. J'en ai mis deux ici. Soit l'indexation qui n'est pas correcte, soit le code SQL qui n'est pas optimal, par exemple un SELECT mal écrit peut-être ne peut pas utiliser un index et donc va être trop coûteux. Il faudrait travailler sur l'amélioration de la requête, sur la création des index qui vont bien. Et puis, bien entendu, en troisième lieu, c'est plutôt le socle, le modèle de données, qui peut-être est défaillant. On est purement dans de l'optimisation. On ne touche pas à la machine avant d'être sûr qu'au niveau du code, de l'indexation et du modèle de données, on ne puisse pas vraiment améliorer les choses. Pourquoi ? Parce que si vous ajoutez des disques plus rapides ou vous augmentez la RAM, eh bien, en manquant l'index, vous allez continuer à parcourir une table toute entière et vous allez améliorer un tout petit peu les performances, mais relativement peu. Par contre, si vous créez un index au bon endroit, vous pouvez facilement transformer une requête qui s'exécutait en 45 secondes, en une requête qui s'exécute en 50 millisecondes. Votre levier au niveau de l'optimisation est bien entendu beaucoup plus important que votre levier au niveau de l'amélioration du matériel. Et, bien entendu, cette composante matérielle est peut-être intellectuellement plus facile à améliorer, alors que l'optimisation ici nécessite plus de temps, plus de réflexion, peut-être plus de compétences, donc c'est parfois plus délicat à mettre en œuvre. Mais il faut passer par là pour vraiment améliorer les performances d'un serveur SQL. Donc c'est pour vous dire, vous faites du diagnostic, mais vous faites attention à vos conclusions, vous cherchez la vraie cause, pas quelque chose qui parait évident au premier abord.

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 !