SQL Server : Optimisation de requêtes efficaces
Concentrez-vous sur le paramétrage des requêtes pour une optimisation réelle des performances de SQL Server et une gestion efficace des charges de travail.
Extraites du « SQL Server DMV Starter Pack », publié par Red porte livres (2010).
Glenn Berry, Louis Davidson et Tim Ford
Réglage de la requête est le cœur et l'âme d'optimisation des performances SQL Server. Si votre charge de travail typique se compose de requêtes inefficaces ou mal conçue, vous allez rencontrer problèmes de performances et évolutivité. Si vos requêtes sont plus longues, plus nombreuses et plus complexe que nécessaire, elles consomment davantage de ressources processeur lors de l'exécution.
Par conséquent, elles prendront également plus de temps à s'exécuter. Requêtes mal conçu, avec un échec de l'utilisation correcte des index, entraîner des SQL Server lecture des données plus que nécessaire. Cela provoque un retard évident dans les performances et la durée d'exécution.
Si SQL Server lit des données à partir du cache, il est appelé e/S logique. Cela peut être une opération coûteuse à partir d'un point de vue des performances. Si les données ne sont pas dans la mémoire et doit être lu à partir du disque (ou si les données doivent être écrites), il s'agit d'e/S physiques et il est encore plus coûteux.
Questions de taille
Si vous disposez de nombreuses requêtes qui retournent des quantités énormes de données, il pourrait provoquer une pression de mémoire sur le cache des tampons. Ainsi, dans les données de consommation SQL Server du cache à son tour affectent les performances des autres requêtes.
« Règle d'or » de requêtes SQL bien conçues consiste à retourner que plus de données que vous doivent vraiment. Vous souhaiterez SQL Server passent par les données que le nombre de fois que possible et l'utilisation logique de jeu pour manipuler les données dans le jeu de résultats que vous avez besoin.
L'analyse et optimisation des instructions SQL ne sont pas une « opération « concurrence élevée ». SQL Server stocke les plans de requêtes exécutées précédemment dans une zone de mémoire partagée appelée le cache de plan. Lorsque vous envoyez une requête pour l'exécution, SQL Server vérifie le cache de plan pour voir si elle peut utiliser un plan existant pour exécuter la requête. Chaque fois qu'il ne trouve aucune correspondance, il analyse, optimise et génère un plan pour la requête soumise. Il s'agit d'un processus intensif du processeur.
En outre, chaque fois que cela, SQL Server acquiert des verrous sur le cache de plan pour protéger la zone de mémoire à partir d'autres mises à jour. Requêtes SQL Server plus ad hoc non paramétrée, on entend par plusieurs plans d'usage unique dans le cache. Cela se traduit par une plus grande consommation de ressources processeur et acquisition de verrous pendant l'analyse. Il peut aboutir dans un système non évolutif. Requêtes SQL bien conçues promouvoir la réutilisation des plans ("analyser une seule fois, utilisez autant de fois") pour la mesure du possible.
Conception de temps à l'esprit
Finalement, si votre charge de travail est constituée de requêtes mal conçues, il entraîne des opérations d'e/S inutiles. Vos frais de processeur et mémoire va ralentir et temps d'exécution sera lents. La situation fera qu'empirer à mesure que le nombre d'utilisateurs augmente. Leurs demandes seront forcés à attendre l'accès aux ressources partagées qui monopolisent les requêtes mal conçus.
À l'inverse, si vous pouvez réduire le nombre d'instructions individuelles de SQL que vous avez besoin pour accomplir une tâche particulière, puis vous pouvez également réduire le travail effectué par chacune de ces instructions SQL individuelles. Vous êtes bien plus susceptibles d'avoir un système de SQL Server rapide et réactif, dimensionnera normalement en tant que le nombre d'utilisateurs et augmente la charge globale.
Une approche souvent utilisé pour le réglage des performances consiste à récupérer une liste des requêtes plus lentes qui font partie de la charge de travail normal et quotidienne sur votre instance de SQL Server et de les régler par un « Top 10 ». Dépister les sessions, les demandes et les requêtes au sein de votre infrastructure SQL Server sont les plus gourmandes en ressources et nécessitent plus de temps à s'exécuter.
Une approche légèrement plus scientifique peut commencer aux niveaux inférieurs, en recherchant des zones spécifiques lorsque SQL Server rencontre sollicitation des ressources. Vérification pour déterminer où les processus en attente anormalement long délai pour une autre action à effectuer avant de continuer. De cette façon, vous pouvez travailler si le composant majeur de la durée d'exécution lente est le temps processeur (si le système est lié à l'UC) ou du temps passé en attente d'e/S (si le système est liée aux e/O) et ainsi de suite.
Vous pouvez ensuite travailler à partir de là pour les demandes qui provoquent les conflits de ressources. Avoir isolé les requêtes de problème, vous pouvez puis trouver un moyen de réduire le volume de travail en cours d'exécution. Cela implique généralement de réglage de vos relevés de SQL et les requêtes ou l'ajout d'index. Si le problème persiste, vous pouvez augmenter la capacité par disque/mémoire/CPU plus de puissance d'achat.
.png)
.png)
.png)
Glenn Berryfonctionne comme un architecte de la base de données au niveau des Technologies NewsGator dans Denver, Colo. Il est un MVP de SQL Server et possède une collection entière de certifications de Microsoft, y compris MCITP, MCDBA, MCSE, MCSD, MCAD et MCTS, ce qui prouve qu'il aime prendre des tests.
**Louis Davidson**a été dans le secteur informatique pendant 16 ans en tant que développeur de base de données d'entreprise et architecte. Il a été un MVP de SQL Server pour six ans et a écrit quatre livres sur la conception de base de données. Actuellement, il est architecte de données et parfois DBA pour le réseau de diffusion chrétiens, prise en charge des bureaux dans Virginia Beach, en Virginie et Nashville, Tennessee
**Grégory Ford**est MVP SQL Server et a travaillé avec SQL Server pour plus de 10 ans. Il est le principal DBA et l'expert de la plate-forme de SQL Server pour la santé du spectre. Il a été écrit sur la technologie depuis 2007 pour une variété de sites Web et gère son propre blog à thesqlagentman.com, couvrant le SQL les rubriques de développement bien comme télétravail et Professionnel.
En savoir plus sur « SQL Server DMV Starter Pack » à red-gate.com/our-company/about/book-store.