Apprendre à optimiser les requêtes SQL et à comprendre les plans d'exécution - Ressources?

Je me retrouve à écrire de plus en plus de requêtes SQL au travail (principalement Oracle 11g, mais certains SQL Server 2005-2008) et j'ai commencé à créer des vues assez complexes pour le reste de l'équipe d'analystes.

Ils courent généralement assez bien, mais certains ne le sont pas si bien. Donc...

• Comment puis-je apprendre à régler mes requêtes?
• Dois-je apprendre à lire / à appliquer les plans d'exécution?

Et...

• Quels livres / sites Web pouvez-vous recommander pour en savoir plus sur l'optimisation des requêtes SQL 1) en général 2) spécifiquement pour Oracle 11g?

Nous avons de bons DBA ici, mais ils sont juste trop submergés pour nous aider à régler chaque requête que nous écrivons.

La plupart des livres que j'ai trouvés sur Amazon pour Oracle semblent tous orientés vers l'optimisation globale de la base de données et / ou ont été écrits il y a 8 à 10 ans.

Merci de vos conseils :)

Je dirais qu'apprendre à comprendre les plans est une compétence vitale pour vous aider à optimiser les instructions SQL. J'ai trouvé le livre de Christian Antognini, Dépannage des performances Oracle , très utile pour détailler leur fonctionnement et expliquer comment aborder l'optimisation de la base de données. Alors qu'il y a quelques années, vous en apprendrez toujours beaucoup qui sont toujours pertinentes.

Si vous devenez plus avancé, vous pouvez consulter les livres de Jonathan Lewis, mais ceux-ci sont plus approfondis, donc probablement pas un bon point de départ. Oracle Fundamentals basé sur les coûts est assez ancien maintenant, mais une grande partie est toujours d'actualité. Je n'ai pas encore lu Oracle Core: Essential Internals for Troubleshooting , mais il a reçu de bonnes critiques de la communauté Oracle.

Comme vous êtes sur 11g, si vous avez des requêtes qui prennent plus de quelques secondes, je recommanderais certainement de regarder le moniteur SQL en temps réel (en supposant que vous disposez d'une licence appropriée). Comme son nom l'indique, il montre la progression d'une instruction SQL en temps réel, décomposant le temps que chaque opération a pris avec les détails des lignes extraites jusqu'à présent. Il conserve également les détails des requêtes récemment exécutées pendant un court instant afin de voir comment vos modifications affectent une instruction.

Documentation Oracle SQL Monitoring: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543

Apprendre à régler les requêtes est quelque chose qui prendra du temps et de la pratique. Quelques choses que j'ai apprises:

• Écrivez des requêtes pour récupérer le moins de lignes possible dès que possible (par exemple, vous ne voulez pas analyser complètement une table de 10 millions de lignes si vous n'en avez besoin que de 100 lignes)
• Vérifiez que le nombre de lignes attendues à chaque étape d'un plan d'explication (attendu) correspond à celles renvoyées dans le plan d'exécution réel. Lorsque ces ordres de grandeur sont différents, il est probable que l'optimiseur ne choisisse pas le "meilleur" plan.
• Comprendre les principes d'une bonne indexation: comment ils fonctionnent et quand ils doivent / ne doivent pas être utilisés lors de l'exécution d'une requête ( Richard Foote a un blog très détaillé sur les index dans Oracle)

La plupart du temps, vous apprendrez en écrivant des requêtes, en examinant les plans d'explication (attendus) et en les comparant aux plans d'exécution réels (soit en traçant la requête, soit en utilisant le moniteur SQL). Réécrivez ensuite la requête, ajoutez / supprimez des index, etc. et voyez comment cela affecte les plans et les temps d'exécution

Comme vous recherchez des informations spécifiques à Oracle, je recommanderais le blog Ask Tom sur Oracle. En général, je pense que vous trouverez que le conseil est de ne pas régler la requête. Vous obtiendrez de bons conseils sur la façon d'écrire une requête que l'optimiseur peut optimiser. La documentation Oracle est également en ligne , et j'y cherche généralement des informations à jour sur Oracle. Je n'ai pas travaillé avec SQLServer donc je n'ai aucune recommandation à ce sujet.

Je n'ai pas vu beaucoup de nouveautés dans le domaine de l'optimisation des requêtes au cours des dernières années. Le grand changement est la dépréciation de l'optimiseur basé sur des règles, avec lequel je me souviens à peine d'avoir travaillé. Cependant, je comprends que SQLServer utilise toujours un optimiseur basé sur des règles, donc comprendre ses règles peut aider.

Un outil dans lequel vous pouvez modifier une requête, l'exécuter et générer un plan d'explication aide à comprendre quels changements vous permettent d'obtenir une requête qui fonctionne bien. J'ai eu de bons résultats avec AquaData Studio, et j'aime vraiment sa vue arborescente. Le développeur SQL devrait faire de même.

Comme pour toute optimisation, vous devez disposer de données quantitatives sur ses performances. Ensuite, vous pouvez déterminer si vous l'avez réellement optimisé.

La façon d'optimiser une requête dépend en partie de la façon dont l'analyseur construit et optimise la requête. Dans une plus large mesure, cela dépend de la distribution des données que vous interrogez. Dans une base de données Oracle, si l'ensemble de résultats représente au moins quatre pour cent d'une table et est distribué de manière aléatoire, une analyse de table est généralement plus rapide qu'un index.

J'ai travaillé à l'optimisation des requêtes pour une équipe de développeurs. Deux ou trois requêtes par an seulement nécessitaient une optimisation sérieuse. La plupart des requêtes sont suffisamment simples pour ne pas nécessiter d'optimisation. Le reste peut généralement être géré en ajoutant des chemins de jointure manquants.

Pour Oracle, il existe trois paramètres réglables qui peuvent avoir un impact significatif sur les performances. Le coût des recherches d'index et de données interagit pour changer les conditions dans lesquelles un index in sera ou ne sera pas utilisé. Ces deux peuvent être réglés sur une base par session. Les valeurs par défaut ne sont souvent pas optimales. L'autre valeur contrôle le nombre d'alternatives que l'optimiseur va essayer. Augmenter cette valeur est souvent utile.

L'optimisation est considérablement affectée par la distribution et le volume des données. Lors de l'optimisation, il est préférable d'utiliser une copie de la base de données de production, ou au moins une base de données avec la même distribution de données et les mêmes volumes. J'ai gravement endommagé l'environnement de test, optimisant une requête pour la base de données des ordres de fabrication. Les bases de données de test et de développement avaient une distribution de données considérablement différente, ce qui entraînait l'échec de la requête, même avec beaucoup moins de données.