preparedstatement java avec like %, lenteur de la requête

concernant le cache des statements qui est partagé ou non :
peut-être que je me trompe, c'est possible

je voudrais néanmoins que quelqu'un réalise mon expérience du post numéro 13.
je re précise que ce post tente de démontrer que le cache n'est pas partagé par tous les clients oracle.

réponse à mnitu :
tu dis :
"PreparedStatement ou Statement vont finir dans un seul et unique « caché » partagé par tous les clients. Du ce point de vue Oracle ne fait pas la différence entre requête avec variable de liaison et sans variable de liaision."

peut-être que le simple statement est mis en cache...
mais quand on change les valeurs que l'on met dans les critères c'est à chaque fois un nouveau statement et donc un nouveau plan d'exécution qui est calculé.

pour répondre à pifor :
je confirme que pour vider le cache des requêtes ceci fonctionne :
ALTER SYSTEM FLUSH SHARED_POOL

c'est très pratique.

par contre je ne sais pas comment interpréter ce que me renvoie la vue V$SQL_SHARED_CURSOR ?

Citation:

---

Envoyé par javaweb44

concernant le cache des statements qui est partagé ou non :
peut-être que je me trompe, c'est possible

je voudrais néanmoins que quelqu'un réalise mon expérience du post numéro 13.
je re précise que ce post tente de démontrer que le cache n'est pas partagé par tous les clients oracle.

---

Avant Oracle 6 le cachée fonctionnait de la manière que vous le décrivez, c’était mauvais. Depuis Oracle6 il est partagé par toutes les connexions. Donc prouver ce que vous dites sera très difficile :aie:. Par contre je vais essayer de vous démontrer le contraire si j’ai le temps ce week-end.

Citation:

---

Envoyé par javaweb44

réponse à mnitu :
tu dis :
"PreparedStatement ou Statement vont finir dans un seul et unique « caché » partagé par tous les clients. Du ce point de vue Oracle ne fait pas la différence entre requête avec variable de liaison et sans variable de liaision."

peut-être que le simple statement est mis en cache...
mais quand on change les valeurs que l'on met dans les critères c'est à chaque fois un nouveau statement et donc un nouveau plan d'exécution qui est calculé.

---

Une requête est envoyée par le client. En gros Oracle calcule un checksum sur cette requête et vérifie si dans le cache il existe un requête appropiée et qui peut être réutilisée (cad déjà analyse et le plan d’exécution déjà élaboré). Si aucune requête ne peut être réutilisée, Oracle fait le hard-parsing. Parmi autre choses dans cette étape il utilise le mécanisme de bind variable peeking que je vous l’ai déjà décrit pour trouver son meilleur plan. Ensuite il lié les variables et il exécute la requête.
S’il trouve une requête qu’il peut réutiliser bref il le réutilise sans élaborer un nouveau plan d’exécution mais en exécutant l’étape de binding de la valeur.
Y compris les requêtes qui n’utilisent pas de variables de liaison (Statement) suivent le même traitement. Seulement qu’une requête qui n’utilise pas de variables de liaison a moins de chances de être réutilisée.

Pour retrouver les paramètres de l'optimiseur essayez

Code:

---

1 2 3 4 5

Select name, value from v$parameter where name like 'optimizer%' /

---

Citation:

---

Envoyé par javaweb44

concernant le cache des statements qui est partagé ou non :
peut-être que je me trompe, c'est possible

je voudrais néanmoins que quelqu'un réalise mon expérience du post numéro 13.
je re précise que ce post tente de démontrer que le cache n'est pas partagé par tous les clients oracle.

---

Je vous propose le test suivant:
Session 1, tester que la requête n'est pas en cache

Code:

---

1 2 3 4 5 6 7 8

C:\Users\Marius>sqlplus mni/mni ... SQL> Select sql_id, executions, parsing_user_id 2 from v$sql 3 where sql_text = 'select ename from scott.emp where empno = :b';   aucune ligne sÚlectionnÚe

---

Session 2, connexion mni/mni, requête avec variables de liaison. Première apparition de la requête donc hard parse

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

C:\Users\Marius>sqlplus mni/mni ... SQL> variable b number; SQL> exec :b := 7369   ProcÚdure PL/SQL terminÚe avec succÞs.   SQL> select ename from scott.emp where empno = :b;   ENAME ---------- SMITH

---

Cherchons cette requête en réexécutant la requête dans la Session 1

Code:

---

1 2 3 4 5 6 7 8 9

SQL> r 1 Select sql_id, executions, parsing_user_id 2 from v$sql 3* where sql_text = 'select ename from scott.emp where empno = :b'   SQL_ID EXECUTIONS PARSING_USER_ID ------------- ---------- --------------- 8z9vfr6d060k3 1 89

---

Maintenant j'ouvre une trosième connexion mais cette fois avec un autre utilisateur: scott à la place de mni. Je change aussi la valeur de la variable de liaison. La requête existe en cache donc soft parse.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

C:\Users\Marius>sqlplus mni/mni ... SQL> variable b number; SQL> exec :b := 7499   ProcÚdure PL/SQL terminÚe avec succÞs.   SQL> select ename from scott.emp where empno = :b;   ENAME ---------- ALLEN

---

Et on reviens à la première session

Code:

---

1 2 3 4 5 6 7 8 9

SQL> r 1 Select sql_id, executions, parsing_user_id 2 from v$sql 3* where sql_text = 'select ename from scott.emp where empno = :b'   SQL_ID EXECUTIONS PARSING_USER_ID ------------- ---------- --------------- 8z9vfr6d060k3 2 89

---

La même requête à été reutilisée du aux variables des liaison (PreparedStatement).

Si je n'utilise pas de variables de liason (Statement) les requêtes ne sont pas idéntiques quand la valeur change et donc il y a hard parse.
Session 2

Code:

---

1 2 3 4 5 6

SQL> select ename from scott.emp where empno = 7369;   ENAME ---------- SMITH

---

Session 1: la nouvelle requête est mise en cache après hard parse

Code:

---

1 2 3 4 5 6 7 8 9

SQL> Select sql_id, executions, parsing_user_id 2 from v$sql 3 where sql_text like 'select ename from scott.emp where empno%';   SQL_ID EXECUTIONS PARSING_USER_ID ------------- ---------- --------------- 7fqqsn0s58r4b 1 89 8z9vfr6d060k3 2 89

---

Session 3, ni cette requête n'est pas dans le cache donc hard parse

Code:

---

1 2 3 4 5 6

SQL> select ename from scott.emp where empno = 7499;   ENAME ---------- ALLEN

---

Et vérification dans Session 1

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SQL> r 1 Select sql_id, executions, parsing_user_id 2 from v$sql 3* where sql_text like 'select ename from scott.emp where empno%'   SQL_ID EXECUTIONS PARSING_USER_ID ------------- ---------- --------------- 7fqqsn0s58r4b 1 89 8z9vfr6d060k3 2 89 b77mayj6faszg 1 89

---

Si je réexécute la dernière requête dans la session 3 ou 2 ou bien 1 elle sera trouvée bien sur dans le cache.

je suis absolument d'accord avec toi mnitu, le comportement que tu décris est aussi celui que j'ai constaté.

mais mon expérience du post numéro 13 n'avait pas pour but de vérifier la réutilisation des requêtes mises dans le cache pour un même client.

cette expérience a pour but de démontrer que chaque client dispose de son propre cache de requête.
donc si tu prends sqldeveloper et que tu exécutes requête1 et qu'ensuite tu prends sqlplus et que tu exécute requête1, oracle va faire 1 hard parse car c'est la première fois que requête 1 est exécutée pour le client sqlplus.

Salut Javaweb44,

D’après ce que tu dit le cache ce n’est pas par client mais par type de logiciel qui se connecte à la base! Parce que trois session sqlplus sont 3 clients pour Oracle.
Bon j’ai fait la même chose avec PL/Sql Developper (je n’ai pas de Sqldevelopper installé sur mon poste mais je vais installer un) et sqlplus et j’ai bien le même résultat.
Mais dans tes tests il faut faire beaucoup d’attention. Les deux requêtes suivantes sont différentes à cause d’un blanc de plus (regarde la colonne length).

Code:

---

1 2 3 4 5 6 7 8 9 10

SQL> SELECT sql_text, length(sql_text) length 2 FROM v$sql 3 WHERE sql_text Like ' SELECT ename FROM scott.emp WHERE empno = :b%' 4 ;   SQL_TEXT LENGTH -------------------------------------------------------------------------------- ---------- SELECT ename FROM scott.emp WHERE empno = :b 45 SELECT ename FROM scott.emp WHERE empno = :b 46

---

ok merci mnitu,
j'ai refais les tests et en effet j'arrive à la conclusion que le cache est partagé par tous ceux qui se connectent à la base.

j'ai dû rajouté par erreur un blanc dans les requêtes de mes expériences de vendredi dernier.

merci.

néanmoins ça ne résoud pas mon problème initial...
je vais reprendre mon problème initial, je reposterai demain pour le reformuler

Voilà, nous sommes bien d’accord que ça ne résout pas ton problème mais maintenant tu sait comment ça marche.
Pour résoudre ton problème c’est pareil il faut comprendre comment ça marche et ce qui se passe. Donc je te propose de relire mon poste initial sur le mécanisme de « bind variable peeking. »