SQL Server 2016 : Maintenance des progiciels tiers

Utiliser SQL Server pour créer des index

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Utilisez les avertissements des plans d'exécution signalant les index manquants. Vous allez ajouter des index qui peuvent réellement améliorer les performances de votre base de données.
08:36

Transcription

Nous venons de voir qu’on pouvait avoir des problèmes d’indexation et qu’il pouvait être utile sur des bases tierces de créer des index nous même. Au pire, on identifie les index et on les soumet à l’éditeur pour demander leur approbation. Mais il n’y a pas de contre-indication médicale particulière à créer un index. Ça ne peut pas troubler l’exécution du code existant, à part un seul type d’index qui est l’index filtré. Je vous montrerais juste après. Mais avant, je vais vous montrer quelque chose qui est un article que j’ai écrit il y a assez longtemps donc sur « rudi.developpez.com » qui va vous aider sur cette étape. Il y a quelques articles et il y en a un qui s’appelle ici « Utiliser les vues dynamiques de gestion pour gérer les index ». Donc vous pouvez dans cet article vous référer directement à la « Table des matières » et aller sur le chapitre « Index manquants ». Vous pouvez sélectionner la requête comme ceci, faire un copier/coller, et retourner dans SQL Server pour lancer la requête. Vous devez être au bon endroit parce que ici je sélectionne la base de données courantes donc je suis dans « PachaDataFormation » ici, je vais me concentrer sur la base de données courantes. Et je vais requêter trois vues systèmes qui gardent en fait, en mémoire depuis le démarrage du serveur les informations d’index manquant qui sont spécifiés dans les plans d’exécution. En un mot, lorsqu’une requête comme celle-ci passe, le plan d’exécution émet un avertissement, dans un certain nombre de cas simples. Pas dans tous les cas. L’indexation est un artisanat, ça peut-être beaucoup plus compliqué que ça mais on va parler ici de cas très simples. Quand les requêtes ont été identifiées, et elles sont assez simples, par le moteur d’optimisation comme pouvant bénéficier d’un index, il est signalé dans le plan d’exécution et ensuite chaque fois qu’on exécute la requête, cette information va être conservée en mémoire. Elle va être accumulée dans des compteurs et vous pouvez le voir ici. Donc je vous lance la requête et vous voyez que sur la colonne « Email », on le voit ici dans « Contact.Contact », eh bien, on pourrait avoir un index. On me dit ici dans « equality_columns » vous voyez, et dans «inequality_columns » quelles sont les colonnes à indexer. Equality parce qu’on fait une égalité, inequality si on cherche sur une différence, et si vous avez les deux, bien vous privilégiez d’abord « equality_columns ». Et vous allez avoir le nombre de fois où on a fait la recherche et où l’index aurait pu être utilisé, et ça vous l’avez ici. Donc on a le nombre de « seeks » c'est-à-dire le nombre de recherches dans l’index. Un index qui est utilisé en « seeks » est très très performant. Et le nombre de « scans », des occurrences où on aurait pu parcourir le dernier niveau de l’index. C’est un peu moins performant mais ça peut-être utile. Vous avez la date de la dernière recherche, la date du dernier scan, et alors surtout « average total user cost », c’est un coût estimé de la requête. Plus la valeur est élevée, et plus la requête est couteuse du point de vue du système. Bon là ça va, c’est pas énorme énorme. Vous avez vu que ça dure 60 millisecondes. Et on a un « average user impact » qui est l’impact moyen sur les 203 fois où on a vu passer les requêtes qu’aurait pu avoir l’index. Donc on voit qu’on a 99,85% d’amélioration des performances. Et ce qui se passe c’est comme j’ai fait ici un « order by user seeks desc » c’est dire on va avoir en premier le nombre de « seeks » ici le plus important. Vous aurez en premier les index les plus intéressants. C’est un bon outil pour juger d’un manque d’index. Si vous voyez, en faisant juste cette requête sur un serveur qui est démarré depuis au moins plusieurs jours, mais l’idéal c’est plusieurs semaine ou plusieurs mois, un nombre très important « d’user seeks » sur des requêtes où le coût est relativement important et vous avez un très fort impact, ça veut dire que ces index sont importants. Il faut considérer de les créer, ça va alléger votre système. Vous voyez que SQL Server vous aide en fait à faire de l’indexation à partir de l’analyse des requêtes qui sont exécutées. Donc ça, c’est très très pratique. Donc voilà, je vous recommande la lecture de l’article et puis l’utilisation de cette requête de façon à juger des améliorations que vous pouvez apporter sur le système en créant des index. Alors je vous disais une chose. Si je veux par exemple créer mon index, ici j’ai ce résultat et je me dis je vais créer mon index sur « Email ». C’est tout ce dont j’ai besoin ici. Je peux venir ici et puis faire un clic-droit sur « Index », créer un « Nouvel index », « Index non clustered ». Ce sera toujours le type d’index que vous allez créer. Et je vais rajouter ici dans la clé l’email. Je vais éventuellement ajouter des colonnes incluses si elles me sont suggérées ici. Je n’en ai pas. « Included columns ». Les colonnes incluses peuvent être intéressantes lorsqu’elles favorisent une requête quand on veut faire un select d’autres colonnes. Par exemple, je veux sélectionner le prénom et le nom seulement. Eh bien je pourrais inclure dans cet index nom et prénom de façon à pouvoir couvrir les besoins de la requête par l’index. C’est un peu plus avancé, mais c’est juste pour vous le signaler si vous voyez qu’il vous suggère des colonnes incluses. S’il y en a deux ou trois, c’est peut-être une bonne idée de les « Ajouter » ici en colonne incluse, comme ceci. Pourquoi je vous dis deux ou trois ? Parce que cet outil a tendance parfois à en ajouter cinq, six, sept, c’est peut-être un peu trop. Mais si vous en voyez deux ou trois, eh bien ajoutez-les, regardez ce que ça fait. Une note sur l’indexation. Lorsque vous ajoutez un index comme ceci, vous allez en cliquant « Ok » créer l’index. Vous allez donc bloquer la table. Si vous êtes en plein milieu d’une situation de production dans la journée, attendez. Peut-être prévoyez de le faire à un moment de faible utilisation, de façon à ne pas troubler déjà un système qui est peut-être chargé. Ne créez pas d’index en plein moment de production. Ça va bloquer un petit peu la table. Mais ce que vous pouvez faire, c’est lorsque vous créez l’index, vous jugez de l’amélioration des performances, peut-être avec le « Profiler » et puis si ça ne vous convient pas, si ça vous donne l’impression que ça n’a rien changé, ou que ça s’empire, ce qui est rarement rarement le cas, même pratiquement jamais, mais on peut-être soit ça améliore, soit ça ne change rien. Eh bien vous pouvez toujours le supprimer après coup en retournant ici et en faisant un clic droit « suppression ». Supprimez uniquement les index que vous avez créés bien entendu, pas des index créés par l’éditeur. Ensuite une dernière chose à ajouter. Vous avez ici la notion de « Filtre ». On peut filtrer l’index, y appliquer une clause « where ». Vous ne le ferez jamais mais je vous le dis juste au cas où, c’est un cas qui peut troubler le code généré par l’éditeur parce que l’index filtré implique que les sessions qui sont ouvertes par le progiciel soient dans un certain état, qu’elles aient certaines options. Donc évitez de faire ça. Mais normalement vous n’aurez jamais à y toucher. Donc je crée mon index sur « Email ». Je fais « ok ». Alors le nom était très très moche. C’est pas tout à fait dans mes habitudes mais tant pis. Et puis, maintenant j’ai un index, je vais regarder ce que ça donne en termes de performance. Je vais reprendre le « Profiler ». Ici, utilisez la petite « gomme » pour effacer la fenêtre. Je reviens, j’exécute, et je regarde ce que ça donne. Ah bah vous voyez il s’est passé quelque chose. J’avais créé un filtre, je pense, je reviens sur la durée qui était supérieure ou égale à 10. Alors il faut que je l’enlève parce que très probablement on est en dessous de 10 maintenant. Donc je recommence. J’arrête pour que ça évite de défiler et voyez ma requête est ici. On est sur 6 « Reads ». Je vous rappelle on en avait 2800 et quelques. On a 0 milliseconde de « CPU ». On en avait 60 avant, on a 0 milliseconde de durée. On en avait à peu près 60 également et on est toujours sur un « Row counts » évidemment. Ça, ça n’a pas changé. Donc vous voyez l’impact que ça peut avoir. Ça peut vous aider. Parfois les requêtes des éditeurs sont un peu compliquées. C’est difficile de faire de l’indexation, mais regardez un petit peu. Parfois il y a quand même des cas simples où ça peut vraiment vous aider.

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 !