Version imprimable
salut ,
dans quel cas un sql_id peut avoir plusieurs child_number ?
Est-ce dans le cas de variable bind ? (Point 1)
Peut-on dire q'un sql_id peut avoir plusieurs plans d'exécution ? et INVERSEMENT :roll:? (Point 2)
Y-a-t-il un lien entre le point 1 et le point 2 ?
merci beaucoup pour vos précisions ...
A+
Jetez un œil dans V$SQL_SHARED_CURSOR
Bref il semble que ma réponse est considéré trop succincte. Comme expliqué dans le lien fourni les raisons pour lesquelles un nouveau curseur enfant est créé sont nombreuses, donc ne sont pas liée seulement aux variables de liaison.
Deux enfant issues d’un même curseur (mais le terme est trompeur parce que il n’existe pas de curseur sans enfant) peuvent avoir des plans d’exécutions différents. Je ne crois pas qu’on peut dire qu’un plan est partagé par plusieurs curseurs mais plutôt que deux curseur enfant peuvent avoir le même plan.
Il y a un lien entre les problèmes de variables de liaison et le nombre de curseurs enfant si on prend en compte juste le mécanisme d’adaptive cursor sharing. Mais comme précisé ce n’est pas la seule raison.
Lorsqu'on utilise les bind variables (les variable de liaison) le but est de partager les ressources. Le plan d’exécution(child_cursor) en fait partie et sera partagé (donc un seul child_cursor = 0) jusqu'au moment où il y a un événement qui expulsera le child_cursor de la SGA ou qu'un changement dans les paramètres de l'optimisateur a lieu provoquant un "hard parse" ou une nouvelle optimisation (donc nouveau child_cursor).
Donc, qui dit bind variable dit partage du plan donc dit un 'seul' child_cursor. Sauf dans le cas où vous êtes en 11gR2 et que votre curseur devient bind aware entraînant l'entrée en jeu de l'adaptive cursor sharing . Dans ce cas oui, plusieurs child_cursor peuvent apparaître pour un même sql_id (même lors de l'utilisation des bind variables). C'est justement un des ''problèmes'' connus de l'adaptive cursor sharing.
En conclusion, oui il est possible d'avoir plusieurs plans d'exécutions(child_cursor) pour un même sql_id mais l'inverse n'a pas de sens à mon sens. Bien qu'il soit possible que différent sql_id peuvent avoir des plans identiques. Dans ce cas ces sql_id ont soit la même force_matching_signature ou bien il ont le même plan hash value (le même plan d'exécution) mais avec des predicats différents comme montré ici
Si vous avez d'autres questions n’hésitez pas
Bonjour,
Il y a des tas de raisons pour lesquelles un curseur va avoir un nouveau child cursor. La présence de bind variable est plutôt là pour aider à partager un curseur, mais de nombreuses raisons peuvent faire qu'un nouveau child cursor est créé quand même.
Oui un même plan d'exécution peut être suivi par des requêtes qui ont un sql_id différent. Il suffit de changer les ordres de jointures, passer des IN en JOIN, ou simplement renommer des alias, etc. Le sql_id et le force_nmatching_signature seront différents, mais le plan le même.
Je ne vois pas de lien entre les 2 points.
Cordialement,
Franck.