Discussion :

[Ikebukuro]

Bonjour,

Ce que je vais dire n'est peut-être pas très clair et donc je m'en excuse.

J'ai compris que dans le Hard parse ou le Soft parse il y a une recherche dans la Shared pool pour voir si un ordre SQL identique à celui en cours de traitement existe déjà. Si c'est le cas, on prends son plan d'exécution, ce qui évite d'avoir à regénérer N plans d'exécution puis en sélectionner un, ce qui est très coûteux en temps de traitement.

J'ai lu qu'une valeur de hash était calculée sur l'ordre SQL et que c'est avec cette valeur qu'on va scanner la Shared pool pour rechercher un ordre SQL équivalent.
Ce que j'aimerais savoir c'est comment est calculée cette valeur de hash.

Si à un instant t le user SCOTT fait "Select nom from EMP where prenom = 'Bambi'" et à un instant t+10 minutes un user JOHN fait "Select nom from EMP where prenom = 'Bambi'" MAIS EMP pointe dans deux schémas différents, sur deux objets de même nom mais avec une structure de table différente, est-ce que la valeur de hash du 2ème ordre SQL va pointer vers le premier ordre SQL et donc récupérer un plan d'exécution qui n'est peut-être pas pertinent?

Autre cas : à un instant t le user SCOTT fait "Select nom from EMP where prenom = 'Bambi'" et à un instant t+10 minutes le même user JOHN, dans la même transaction, fait encore "Select nom from EMP where Prenom = 'Bambi'". Dans le premier cas on utilise un index car prenom = 'Bambi' pointe vers 0.1% des employés.
Je pense que dans le deuxième cas on va pointer vers le plan d'exécution du premier ordre SQL MAIS entre les deux SELECT on a inséré dans la table N données avec Prénom = Bambi --> on a cette fois prenom = 'Babmbi' représentant 50% des employés. Si on réutilise le plan d'exécution du premier Select, on utilise un index alors qu'un full table scan serait plus pertinent... je me trompe?

[mnitu]

Je pense à avoir vu sur le site de Tanel Poder des détails sur le calcul de la fonction de hachage mais je ne vois pas en quoi cela vous aidera actuellement.

Il n'y a pas que le texte de la requête qui doit être identique mais aussi l'environnement qui a déterminé le plan! Exemple: le simple fait de activer la trace détermine le hard parsing de la requête! Cela c'est pour dire que si le texte de la requête est identique mais les tables sont dans des schémas différentes c'est du hard parsing que Oracle va faire. Et il y en a des autres aspect et mécanismes qui intervienne à chaque version d'Oracle.

Autre remarque le texte de la requête est sensible aux majuscules minuscules et aussi espaces blanc, etc. C'est la rasoin principale pour laquelle le PL/SQL "normalise" ses requêtes avant de les envoyer à l'optimiseur.

Attention aussi à vos exemples: vous n'utilise pas des variables de liaisons (bind variables) et toute l'idée de récupération du plan n'est effectivement valable que dans ce contexte.

Dernière question: si les données sont extrêmement fluides alors il faut anticiper cette situation en recalculant les statistiques, ce qui invalide les plans ou à employer le mécanisme de dynamic sampling.

[Ikebukuro]

Hello mnitu,

Je te remercie pour ta réponse. Pour les bind variables, c'était un oubli de ma part mais ce que je voulais effectivement savoir c'était si le changement du contexte (des données en moins ou en plus, des pourcentages qui changent) avait une influence sur le choix du plan d'exécution en SGA ou non.

Je vais voir prochainement le site de Tanel Poder.

[pachot]

Bonjour,
Ta compréhension est bonne. Mais il faut maintenant rajouter la notion de 'parent cursor' et 'child cursor'
Même text sql -> même parent cursor
Ensuite, il y a toutes les vérification pour voir si on peut partager un 'child cursor' ou non. Par exemple, su schema différent -> nouveau child cursor (et donc hard parse)
Pour la table que change de volume, si on charge beaucoup de données, il est bon de recalculer les stats, et ça va déclencher une invalidation des cursor, et donc un nouveau hard parse
Cordialement,
Franck.