Plan d'exécution avec un bind variable

bonne nouvelle.

execute la requête suivante pour voir sir le plan d'execution pour les 2 child sont différents:

Code:

---

1 2	select distinct child_number, plan_hash_value from v$sql_plan where sql_id = 'd4mkvkrz4q58s';

---

puis execute cette requête pour voir le mismatch entre les 2 childs:

Code:

---

1 2	select * from v$sql_shared_cursor where sql_id = 'd4mkvkrz4q58s';

---

ce qui serait intéressant de voir, ce sont les raisons des différences entre les deux child cursor (càd les colonnes de v$sql_shared_cursor )

un troisième child cursor a effectivement pû être généré mais il a peut être tout simplement été "aged out" de la cache

pour ce qui est d'abandonner les bind variables, la bonne pratique en 10g est d'utiliser des bind variables lorsque la dispersion de tes données est homogène . si tu dois sélectionner des données qui ont une cardinalités très différentes de celles utilisées pour le bind peeking, n'utilise dans ce cas précis pas de bind variable

les options 11g bind sensitives règlent plus ou moins ce problème

1 seul plan d'exécution

Code:

---

1 2 3

CHILD_NUMBER PLAN_HASH_VALUE ------------ --------------- 2 3366992749

---

mismatch

Code:

---

1 2 3 4

SQL_ID ADDRESS CHILD_AD CHILD_NUMBER U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F A I T D L D B P C S R P T M B M R O P M F L ------------- -------- -------- ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - d4mkvkrz4q58s 301DBB5C 3362755C 0 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N d4mkvkrz4q58s 301DBB5C 31A17264 2 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N

---

A mon avis suite à l'invalidation que j'avais faite sur le curseur, j'ai 1 seul plan d'exécution valide. Il faudrait juste refaire tout ca quand le plan d'exécution qui fait un FTS se représente.
De toute manière j'ai vu avec les responsables applicatif, c'est un bug du progiciel qui alimente cette table (historique des actions) pour un document en erreur.
La boucle est bouclé, on va purger la table des historiques sur le document incriminé avec la validation de l'éditeur :)

Merci pour vos lumières