Je suis nouveau chez Oracle et chez 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 FULL. 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?
Réponses
Trop de publicités?
La sortie d'EXPLIQUER le PLAN est une sortie de débogage à partir d'Oracle de l'optimiseur de requête. Le COÛT est le résultat final de l'fondée sur le Coût de l'optimiseur (CBO), dont le but est de sélectionner les différents plans possibles devrait être utilisé pour exécuter la requête. Le CBO calcule un Coût relatif pour chaque plan, prend alors le plan avec le prix le plus bas.
(Remarque: dans certains cas, l'association ne dispose pas d'assez de temps pour évaluer chaque plan possible; dans ces cas, il choisit juste au régime avec le coût le plus bas trouvé à ce jour)
En général, l'un des plus gros contributeurs à une requête lente est le nombre de lignes lues au service de la requête (blocs, pour être plus précis), de sorte que le coût sera basé en partie sur le nombre de lignes de l'optimiseur estimations devront être lu.
Par exemple, disons que vous avez de la requête suivante:
SELECT emp_id FROM employees WHERE months_of_service = 6;
(L' months_of_service colonne a une contrainte not NULL sur elle et ordinaire de l'index sur elle.)
Il existe deux régimes de base de l'optimiseur peut choisir ici:
- Plan 1: Lire les lignes de la "employés" de la table, pour chacun, de vérifier si le prédicat est vrai (
months_of_service=6). - Plan 2: Lecture de l'index où
months_of_service=6(ce qui résulte en un ensemble de ROWIDs), puis d'accéder à la table basée sur la ROWIDs retourné.
Imaginez les "employés" de la table est de 1 000 000 (1 million) de lignes. Nous allons imaginer davantage que les valeurs pour months_of_service gamme de 1 à 12 et sont assez uniformément répartis pour une raison quelconque.
Le coût du Plan 1, ce qui implique une ANALYSE COMPLÈTE, sera le coût de la lecture de toutes les lignes dans la table employés, ce qui est approximativement égal à 1 000 000; mais depuis Oracle sera souvent en mesure de lire les blocs à l'aide de multi-bloc de lit, le coût réel est inférieur (tout dépend de votre base de données est mis en place) - par exemple, imaginons que le multi-bloc de lire le nombre est de 10 le coût calculé de l'analyse complète sera de 1 000 000 / 10; Overal coût = 100 000 habitants.
Le coût du Plan 2, ce qui implique un INDEX RANGE SCAN et une table de recherche par ROWID, sera le coût de la numérisation de l'indice, plus le coût de l'accès à la table par ROWID. Je n'entrerai pas dans la façon dont l'indice de gamme analyses sont chiffrées mais imaginons le coût de l'index range scan est de 1 par ligne; nous nous attendons à trouver une correspondance dans 1 des 12 cas, et donc le coût de l'analyse d'index est de 1 000 000 / 12 = 83,333; plus le coût de l'accès à la table (à supposer 1 bloc de lire par accès, nous ne pouvons pas utiliser le multi-bloc lit ici) = 83,333; coût Global = 166,666.
Comme vous pouvez le voir, le coût du Plan 1 (full scan) est inférieur au coût du Plan 2 (index scan + accès par rowid) ce qui signifie que le CBO choisissez le scan COMPLET.
Si les hypothèses formulées ici par l'optimiseur sont vraies, alors en fait Plan 1 sera préférable et beaucoup plus efficace que le Régime 2 - qui réfute le mythe que des analyses COMPLÈTES sont "mauvais".
Le résultat serait tout à fait différente si l'optimiseur objectif était FIRST_ROWS(n) au lieu de ALL_ROWS - dans ce cas, l'optimiseur serait en faveur du Plan 2, car il va souvent de retour de la première quelques lignes plus rapide, au prix d'être moins efficace pour l'ensemble de la requête.
MichaelN
Points
1009
Le CBO construit un arbre de décision, l'estimation des coûts de chaque chemin d'exécution disponibles par requête. Les frais sont fixés par le CPU_cost ou I/O_cost jeu de paramètres sur l'instance. Et le CBO estime les coûts, mieux qu'elle peut avec les statistiques de l'index et les tables de la requête à utiliser. Vous ne devriez pas régler votre requête basée sur les seuls coûts. Coût permet de comprendre POURQUOI l'optimiseur est en train de faire ce qu'il fait. Sans frais vous pourriez comprendre pourquoi l'optimiseur a choisi la plan elle l'a fait. Faible coût ne signifie pas une requête plus rapide. Il y a des cas où c'est vrai et il y a des cas où cela est faux. Le coût est basé sur votre table stats et si elles sont mauvaises, le coût va être mauvais.
Lors du paramétrage de votre requête, vous devriez jeter un oeil à la cardinalité et le nombre de lignes de chaque étape. Ont-elles un sens? Est la cardinalité de l'optimiseur est en supposant que correcte? Est les lignes de retour raisonnable. Si l'information présente est faux il est alors très probable que l'optimiseur n'a pas les bonnes informations dont il a besoin pour prendre la bonne décision. Cela pourrait être dû à obsolètes ou manquantes statistiques sur la table et l'index ainsi que cpu-stats. De son mieux pour avoir des statistiques mises à jour lors du paramétrage d'une requête pour obtenir les la plupart hors de l'optimiseur. Sachant que votre schéma est également d'une grande aide lors de l'optimisation. Sachant que lorsque l'optimiseur choisit vraiment une mauvaise décision et pointant dans la bonne voie avec un petit soupçon pouvez enregistrer une charge de temps.
drowe
Points
1511
Ici est une référence pour EXPLIQUER à l'aide de PLAN avec Oracle: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm), avec des informations spécifiques sur les colonnes que l'on retrouve ici: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i18300
Votre mention de "à part entière", m'indique que la requête est en train de faire une analyse complète de la table pour trouver vos données. Ce n'est pas grave, dans certaines situations, sinon un indicateur d'une mauvaise indexation / requête d'écriture.
Généralement, avec les plans d'explication, vous voulez vous assurer que votre requête en utilisant les touches, ainsi Oracle peut trouver les données que vous recherchez avec l'accès le moins de lignes possible. En fin de compte, vous pouvez parfois seulement obtenir jusqu'à présent avec l'architecture de vos tables. Si les coûts restent trop élevé, vous pourriez avoir à penser sur le réglage de la mise en page de votre schéma pour être plus basée sur la performance.
David Aldridge
Points
27624
Dans les dernières versions d'Oracle le COÛT représentent la quantité de temps que l'optimiseur s'attend à ce que la requête de prendre, exprimée en unités de la quantité de temps nécessaire pour qu'un seul bloc de lecture.
Donc, si un seul bloc de lecture prend 2ms et le coût est exprimé en tant que "250", la requête peut être prévu de prendre 500ms pour terminer.
L'optimiseur calcule le coût en fonction de l'estimation du nombre de bloc unique et multiblock lit, et la consommation CPU du plan. ce dernier peut être très utile dans la réduction de ces coûts de l'exécution de certaines opérations avant les autres pour essayer d'éviter de haute CPU coût des opérations.
Cela soulève la question de savoir comment l'optimiseur sait combien de temps les opérations. dernières versions d'Oracle permettre les collections de "système de statistiques", qui sont certainement à ne pas confondre avec les statistiques sur les tables ou index. Le système de statistiques sont des mesures de la performance du matériel, et surtout:
- Combien de temps d'un seul bloc de lecture prend
- Combien de temps un multiblock lecture prend
- Comment grand un multiblock lire est (souvent différents au maximum possible grâce à la table des extensions étant plus petit que le maximum, et pour d'autres raisons).
- Les performances du PROCESSEUR
Ces nombres peuvent varier considérablement en fonction de l'environnement de fonctionnement du système, et différents ensembles de statistiques peuvent être stockées pour la "journée OLTP" et "la nuit de la déclaration par lots" et "à la fin du mois de déclaration" si vous le souhaitez.
Compte tenu de ces séries statistiques, un plan d'exécution de requête peuvent être évalués au coût dans les différents environnements d'exploitation, ce qui pourrait favoriser l'utilisation des analyses de tables complètes à certains moments ou analyses à index à d'autres.
Le coût n'est pas parfait, mais l'optimiseur est de mieux en mieux à l'auto-surveillance à chaque mise à jour, et peut rétroaction le coût réel en comparaison de l'estimation des coûts, afin de prendre de meilleures décisions pour l'avenir. cela rend également plus difficile à prédire.
Notez que le coût n'est pas nécessairement horloge murale temps, en parallèle, les opérations de requête consommer un montant total de temps entre plusieurs threads.
Dans les anciennes versions de Oracle le coût des opérations CPU a été ignorée, et les coûts relatifs de l'unique et multiblock lectures ont été fixés de façon efficace en fonction d'initialisation des paramètres.
stili
Points
598
PLEIN est probablement référence à un full table scan, ce qui signifie qu'aucun index n'est en cours d'utilisation. C'est habituellement ce qui indique que quelque chose est faux, à moins que la requête est censé utiliser toutes les lignes dans une table.
Le coût est un nombre qui indique la somme des charges différentes, processeur, mémoire, disque, IO, et le nombre élevé sont généralement mauvais. Les numéros sont ajoutés lors du déplacement à la racine du plan, et chaque branche doit être examiné afin de localiser les goulets d'étranglement.
Vous pouvez également interroger v$sql et v$session d'obtenir des statistiques sur SQL, et cela va avoir des paramètres détaillés pour tous les types de ressources, les horaires et les exécutions.
