Compréhension des résultats d'Execute Explain Plan dans Oracle SQL Developer
J'essaie d'optimiser une requête, mais je ne comprends pas très bien certaines des informations renvoyées par Explain Plan. Quelqu'un peut-il me dire la signification des colonnes OPTIONS et COST? Dans la colonne OPTIONS, je ne vois que le mot COMPLET. Dans la colonne COST, je peux en déduire qu'un coût inférieur signifie une requête plus rapide. Mais que représente exactement la valeur du coût et quel est le seuil acceptable?
La sortie de EXPLAIN PLAN est une sortie de débogage de l'optimiseur de requêtes d'Oracle. COST est le résultat final de l'optimiseur basé sur les coûts (CBO), dont le but est de sélectionner lequel des nombreux plans possibles doit être utilisé pour exécuter la requête. Le CBO calcule un coût relatif pour chaque plan, puis choisit le plan avec le coût le plus bas.
(Remarque: dans certains cas, l’OBC ne dispose pas de suffisamment de temps pour évaluer tous les plans possibles; dans ce cas, il choisit simplement le plan avec le coût le plus bas trouvé jusqu’à présent.)
En général, l’un des principaux contributeurs à une requête lente est le nombre de lignes lues pour répondre à la requête (blocs, pour être plus précis), le coût sera donc basé en partie sur le nombre de lignes que les estimations de l'optimiseur devront être lues.
Par exemple, supposons que vous ayez la requête suivante:
SELECT emp_id FROM employees WHERE months_of_service = 6;
(Le months_of_service column comporte une contrainte NOT NULL et un index ordinaire.)
L’optimiseur peut choisir ici deux plans de base:
- Plan 1: Lisez toutes les lignes du tableau "Employés". Vérifiez si le prédicat est vrai (
months_of_service=6). - Plan 2: Lire l'index où
months_of_service=6(il en résulte un ensemble de ROWID), puis accédez à la table en fonction des ROWID renvoyés.
Imaginons que la table "employés" comporte 1 000 000 (1 million) de lignes. Imaginons en outre que les valeurs de months_of_service vont de 1 à 12 et sont réparties de manière assez homogène pour une raison quelconque.
Le coût de Plan 1, qui implique un balayage complet, correspond au coût de lecture de toutes les lignes de la table des employés, ce qui correspond approximativement à 1 000 000; mais comme Oracle sera souvent capable de lire les blocs en utilisant des lectures multi-blocs, le coût réel sera plus bas (en fonction de la configuration de votre base de données) - par ex. imaginons que le nombre de lectures multi-blocs soit égal à 10 - le coût calculé de l'analyse complète sera de 1 000 000/10; Coût total = 100 000.
Le coût de Plan 2, qui implique un INDEX RANGE SCAN et une recherche de table par ROWID, correspond au coût de l'analyse de l'index, plus le coût d'accès à la table par ROWID. Je n'entrerai pas dans le calcul du coût des analyses de la plage d'index, mais imaginons que le coût de l'analyse de la plage d'index est de 1 par ligne; nous nous attendons à trouver une correspondance dans 1 cas sur 12, le coût de l'analyse de l'indice est donc de 1 000 000/12 = 83 333; plus le coût d'accès à la table (supposons 1 lecture de bloc par accès, nous ne pouvons pas utiliser des lectures de plusieurs blocs ici) = 83 333; Coût global = 166 666.
Comme vous pouvez le constater, le coût du plan 1 (analyse complète) est inférieur au coût du plan 2 (analyse de l'index + accès par ID de ligne), ce qui signifie que le CBO choisirait l'analyse FULL.
Si les hypothèses faites ici par l'optimiseur sont vraies, alors Plan 1 sera préférable et beaucoup plus efficace que Plan 2 - ce qui réfute le mythe selon lequel les analyses FULL sont "toujours mauvaises".
Les résultats seraient assez différents si l'objectif de l'optimiseur était FIRST_ROWS (n) au lieu de ALL_ROWS. Dans ce cas, l'optimiseur privilégierait Plan 2 car il renverrait souvent les premières lignes plus rapidement, au prix d'une efficacité moindre pour l'ensemble de la requête. .
Le CBO construit un arbre de décision, en estimant les coûts de chaque chemin d’exécution possible disponible par requête. Les coûts sont définis par le paramètre CPU_cost ou I/O_cost défini sur l'instance. Et le CBO estime les coûts, du mieux qu'il peut avec les statistiques existantes des tables et des index que la requête utilisera. Vous ne devez pas ajuster votre requête en fonction du coût uniquement. Le coût vous permet de comprendre POURQUOI l'optimiseur fait ce qu'il fait. Sans frais, vous pouvez comprendre pourquoi l'optimiseur a choisi le plan qu'il a choisi. Un coût inférieur ne signifie pas une requête plus rapide. Il y a des cas où cela est vrai et il y aura des cas où cela est faux. Le coût est basé sur les statistiques de votre table et s’ils se trompent, ils se tromperont.
Lors du réglage de votre requête, vous devriez examiner la cardinalité et le nombre de lignes de chaque étape. Ont-ils un sens? La cardinalité supposée par l’optimiseur est-elle correcte? Est-ce que les lignes retournées sont raisonnables? Si les informations présentées sont erronées, il est très probable que l'optimiseur ne dispose pas des informations adéquates pour prendre la bonne décision. Cela peut être dû à des statistiques obsolètes ou manquantes sur la table et à l'index, ainsi qu'à la statistique cpu. Il est préférable de mettre à jour les statistiques lors du réglage d'une requête pour tirer le meilleur parti de l'optimiseur. Connaître votre schéma est également d'une grande aide lors du réglage. Savoir quand l'optimiseur a pris une très mauvaise décision et la placer dans le bon chemin avec un petit indice peut vous faire gagner beaucoup de temps.
Voici une référence pour utiliser EXPLAIN PLAN avec Oracle: http://download.Oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm ), avec des informations spécifiques sur le colonnes trouvées ici: http://download.Oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i183
Votre mention de 'FULL' m'indique que la requête effectue une analyse de table complète pour trouver vos données. Ceci est correct, dans certaines situations, sinon un indicateur de faible indexation/écriture de requête.
En règle générale, avec les plans Explication, vous souhaitez vous assurer que votre requête utilise des clés. Oracle peut ainsi trouver les données que vous recherchez en accédant au plus petit nombre possible de lignes. En fin de compte, vous ne pouvez parfois aller que très loin avec l’architecture de vos tables. Si les coûts restent trop élevés, vous devrez peut-être adapter la disposition de votre schéma pour qu'il soit davantage basé sur les performances.
Dans les versions récentes d'Oracle, la valeur COST représente le temps que l'optimiseur attend de la requête, exprimé en unités du temps requis pour une lecture par bloc.
Ainsi, si une lecture de bloc unique prend 2 ms et que le coût est exprimé par "250", la requête devrait prendre 500 ms.
L'optimiseur calcule le coût en fonction du nombre estimé de lectures de bloc unique et de multibloc et de la consommation de CPU du plan. ce dernier peut être très utile pour réduire les coûts en effectuant certaines opérations avant les autres pour éviter les opérations coûteuses en ressources processeur.
Cela soulève la question de savoir comment l'optimiseur sait combien de temps les opérations prennent. Les versions récentes d'Oracle autorisent les collections de "statistiques système", qu'il ne faut absolument pas confondre avec les statistiques sur les tables ou les index. Les statistiques du système sont des mesures de la performance du matériel, principalement:
- Combien de temps dure une lecture par bloc
- Combien de temps prend une lecture multibloc
- Quelle est la taille d'une lecture multibloc (souvent différent du maximum possible en raison des étendues de table inférieures au maximum et pour d'autres raisons).
- Performances du processeur
Ces chiffres peuvent varier considérablement en fonction de l'environnement d'exploitation du système. Différents ensembles de statistiques peuvent être stockés pour les opérations "OLTP de jour" et les "rapports de lot de nuit", ainsi que pour les "rapports de fin de mois".
Compte tenu de ces ensembles de statistiques, un plan d’exécution de requête donné peut être évalué en termes de coût dans différents environnements d’exploitation, ce qui peut favoriser l’utilisation d’analyses de tables complètes à certains moments ou d’indexations à d’autres.
Le coût n’est pas parfait, mais l’optimiseur s’auto-surveille de mieux en mieux à chaque nouvelle version et peut comparer le coût réel par rapport au coût estimé afin de prendre de meilleures décisions pour l’avenir. Cela le rend également plus difficile à prédire.
Notez que le coût n’est pas nécessairement l’horloge murale, car les opérations de requête parallèle consomment une durée totale sur plusieurs threads.
Dans les anciennes versions d'Oracle, le coût des opérations de la CPU était ignoré et les coûts relatifs des lectures en mono et multibloc étaient effectivement fixés en fonction des paramètres init.
FULL fait probablement référence à une analyse complète de la table, ce qui signifie qu'aucun index n'est en cours d'utilisation. Cela indique généralement que quelque chose ne va pas, sauf si la requête est supposée utiliser toutes les lignes d'une table.
Le coût est un nombre qui indique la somme des charges, du processeur, de la mémoire, du disque, des E/S et des nombres élevés différents. Les chiffres sont additionnés lors du déplacement à la racine du plan, et chaque branche doit être examinée pour localiser les goulots d'étranglement.
Vous pouvez également interroger v $ sql et v $ session pour obtenir des statistiques sur les instructions SQL. Ces mesures fourniront des métriques détaillées pour tous les types de ressources, de minutages et d'exécutions.