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 : Maintenance des progiciels tiers

Optimiser pour les charges de travail ad hoc

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Appliquez l'option Optimiser pour les charges de travail ad hoc. Il s'agit de limiter l'impact du cache de plans en mémoire.
06:16

Transcription

Nous avons vu que nous pouvons améliorer les choses avec la compression, avec la compression qui existe depuis SQL SERVEUR 2008 mais disponible qu’en édition entreprise. Je vais vous montrer maintenant deux ou trois options de configuration qui vont pouvoir vous aider si vous êtes aussi en édition standard. Eh bien entendu, également en édition entreprise, c'est tout à fait valable. Première chose, ce qu'on appelle le « cache de plan ». Pour vous illustrer ça, j'ai fait toute une suite ici de requêtes qui se ressemblent quand même très nettement « SELECT* FROM Contact.Contact where le Nom est égal à... » et j'ai listé toute une série de nom. La requête est toujours en cours d'ailleurs, ça fait six minutes qu'elle tourne parce qu'elle doit requêter chaque nom individuellement et c'est tout à fait ce que pourrait faire une application cliente dans un progiciel, faire des recherches avec des paramètres différents comme ici. SQL Server, au niveau des plans d'exécution qu’il va générer pour chaque requête, va très souvent, selon en fait l’indexation, selon le type de la requête, « est-ce que c’est une requête triviale ou non? », eh bien, très souvent il va garder en cache le plan d'exécution, ce qu'il fait systématiquement pour toutes les requêtes de façon à s'économiser le calcul du plan d'exécution à la prochaine rencontre de cette requête. Mais très souvent, pour une requête qui a à-peu-près le même squelette, la même structure ici, mais simplement avec des changement de paramètre, eh bien il risque de conserver dans son cache en mémoire vive plusieurs fois le même plan, parce qu'il va calculer, eh bien à chaque fois un plan et le cacher à chaque fois, je vais vous montrer. Je vais arrêter peut-être ma requête de façon à ne pas charger ma machine, je viens ici et je vais lancer une requête sur une vue système, une vue de gestion dynamique qui s'appelle "dm_exec _ cached_ plans" et qui va me donner le détail des plans qu'ils ont cachés en mémoire. Et là, je vais me concentrer uniquement sur des plans « compilés » et voyons ce que ça donne. Alors, comme vous le voyez j'ai un certain nombre de plans compilés qui sont mes « SELECT* FROM Contact.Contact » et la taille de chaque plan, les plans sont des structures en « XML » qui sont conservées en mémoire et au minimum de 16 kilos, donc je vois que j’ai chaque fois 16 ko. Et en fait si je fais un calcul, je reprends une requête, je regarde tous les plans compilés qui ont été utilisés qu'une fois, parce que comme vous le voyez ici j'ai un compteur d'utilisation des plans en mémoires qui est le « usecounts » et qui montre ici chaque fois « 1 ». Je n'ai lancé qu'une seule fois à la requête. Eh bien, si je fais un total, j'ai pour l'instant environ 6 mégaoctets de plans qui ont été utilisés qu'une seule fois en mémoire. Bon, ici ce n’est pas beaucoup parce que c'est ma machine de cours, mais sur un serveur de production, admettons, vous avez disons 24 gigas de RAM. Vous avez un serveur de production, il tourne depuis quelques semaines, eh bien vous aurez probablement au moins quatre ou cinq gigas occupés par le cache de plan. Sur ces quatre ou cinq gigas il est tout à fait possible que vous ayez au moins la moitié qui soit occupée par des plans qui n’ont été utilisés qu'une seule fois, parce que le raisonnement, c'est que votre application client de votre progiciel va envoyer des requêtes avec des critères différents. Chaque fois vous faites des recherches sur un nom en particulier et chaque fois vous aurez 16 kilos de plan en mémoire. Vous avez une option très simple pour limiter l'impact de ces plans en mémoire. Je vais sur mon serveur, sur mon instance, clic-droit dans les propriétés de l'instance, dans la partie avancée. Il existe ici depuis SQL serveur 2008, je vous le montre, une option qui s'appelle « Optimiser pour les charges de travail ad hoc ». Si vous avez SQL Server en anglais, « Optimize for ad hoc work loads ». Qu’est-ce que c'est qu’une charge de travail ad hoc? Eh bien, c'est justement ce qu'on vient de voir, des requêtes qui sont envoyées en pur texte au serveur. L'option est par défaut à « False » parce qu'elle a été introduite en « SQL serveur 2008 » et que Microsoft ne change pas des options par défaut sans prévenir les utilisateurs, donc c'est à vous de modifier cette option, et de mon point de vue elle devrait toujours être à « True ». Il y a pas de raison de la mettre à « False » parce que ça va toujours améliorer les choses, il n'y a pas de cas où le fait de la mettre à « True » va diminuer les performances ou avoir des effets indésirables. Donc, mettez-la à « True », vraiment. Je vais vous montrer l'effet, et donc c'est à chaud, vous n'avez pas besoin de relancer votre serveur, il n'y a pas de problème. Je vais revenir ici, je vais vider à l'aide de cette commande, mon cache de plan en mémoire. Voilà. Et je vais en lancer juste quelques-unes. Ce n’est pas la peine d'aller plus loin, et on va voir maintenant ce qu'il y a en mémoire. Vous voyez que je n’ai plus de plans compilés. Je vais modifier cette requête pour voir si j'ai autre chose. Et effectivement j'ai des « SELECT * FROM contact.contact », mais ce ne sont plus des plans compilés. Vous voyez ici, ce sont des « stub », c'est-à-dire la signature du plan, celui-ci n'a pas été conservé en mémoire mais on a gardé une trace de la requête. Et ça fait maintenant 384 octets au lieu des 16 kilos précédents. Ce qui veut dire que SQL Server, lorsqu’il voit passer une première fois la requête, il ne conserve que sa signature, pour savoir si elle va être exécutée à nouveau, et lorsque je vais ré-exécuter les requêtes, eh bien cette fois-ci, j'ai bien mon plan compilé, donc SQL Server attend de voir passer une deuxième fois la même requête pour se dire cette fois-ci : « cette requête a des chances de passer encore plusieurs fois donc ça vaut la peine de conserver en cache le plan d'exécution. Et donc, je garde mon plan d'exécution en cache mais seulement la deuxième fois. » Donc ça va vous économiser de la mémoire, probablement un ou deux gigas au moins et c'est toujours ça de pris pour avoir plus de mémoire pour le cache de données.

SQL Server 2016 : Maintenance des progiciels tiers

Exploitez les fonctionnalités de SQL Server afin de diminuer les problèmes, et améliorer les performances des progiciels. Faites face à ce problème très souvent rencontré !

1h16 (15 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :4 août 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 !