Discussion :

[CssFaxien]

Bonjour

comment supprimer les plan d'exécution des requêtes ????

Merci

[Pomalaix]

Les supprimer d'où ?? Et dans quel but ?

Par ailleurs, il faut systématiquement indiquer votre version d'Oracle ; c'est un élément essentiel pour une réponse adaptée.

[CssFaxien]

- j'utilise oracle 11g

- je veux les supprimer de la cache

- le but : pour que l’optimiseur de requêtes n'utilise pas les plan d'exécutions existants et créé un nouveau plan d’exécution pour chaque requête qui tient compte de la présence de nouveaux index.

( ça entre dans un cadre expérimental pour une évaluation de performance )

Merci

[Pomalaix]

- le but : pour que l’optimiseur de requêtes n'utilise pas les plan d'exécutions existants et créé un nouveau plan d’exécution pour chaque requête qui tient compte de la présence de nouveaux index.

Ce point là m'échappe : ça se passe déjà comme ça par défaut !

Mais peut-être que ceci vous intéresse (V11) : ça permet de supprimer un curseur et ses plans associés du cache.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select address, hash_value from v$sqlarea where sql_text = 'select * from dept';
 
ADDRESS HASH_VALUE
-------- ----------
2671F27C 3599690174
 
exec dbms_shared_pool.purge('2671F27C,3599690174','C');

[Ahmed AANGOUR]

Bonjour,

J'ai écris un article il y'a 2 mois sur ce sujet:
http://ahmedaangour.blogspot.com/201...ared-pool.html

[CssFaxien]

Bonjour,

J'ai écris un article il y'a 2 mois sur ce sujet:
http://ahmedaangour.blogspot.com/201...ared-pool.html

Merci Mr Ahmed

[CssFaxien]

oui en principe c'est par défaut . j'ai mal expliqué
lorsque j’exécute ma requête pour la première foi elle prend un temps de réponse 14 seconde et pour la deuxième foi 3 s .
alors pour faire des comparaison je pense qu'il faut supprimer les plan d'exécution de la cache pour avoir des résultats significatifs .

Merci

[Ahmed AANGOUR]

oui en principe c'est par défaut . j'ai mal expliqué
lorsque j’exécute ma requête pour la première foi elle prend un temps de réponse 14 seconde et pour la deuxième foi 3 s .
alors pour faire des comparaison je pense qu'il faut supprimer les plan d'exécution de la cache pour avoir des résultats significatifs .

Merci

Il y'a de fortes chances qu'à la 2ème exécution les données à récupérer sont déjà dans le cache et donc la requête est plus rapide car pas d'accès disque à faire.
Pour en être sûr, vous pouvez exécuter votre requête sous SQLPLUS comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ALTER SESSION SET STATISTICS_LEVEL=ALL;
SET LINES 500
SET PAGES 500
<EXECUTEZ ICI VOTRE REQUETE>
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null,null,'ALLSTATS LAST'));
 
<EXECUTEZ ICI VOTRE REQUETE une 2ème fois>
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null,null,'ALLSTATS LAST'));

Faites nous parvenir ensuite les 2 plans générés.

[Pomalaix]

lorsque j’exécute ma requête pour la première foi elle prend un temps de réponse 14 seconde et pour la deuxième foi 3 s .
alors pour faire des comparaison je pense qu'il faut supprimer les plan d'exécution de la cache pour avoir des résultats significatifs

Comme Ahmed le suggère, c'est un effet de cache au niveau des données, et non au niveau du code SQL.

S'il y a quelque chose à purger, ce sont donc les données des tables et index touchés par votre requête.
Pour ça, je ne connais aucune méthode suffisamment sélective.
ALTER SYSTEM FLUSH BUFFER_CACHE, ou la mise hors ligne momentanée du tablespace sont bien trop globaux.

Notre ami Tom Kyte a une autre vision de la chose : ne surtout pas chercher à vider le cache de données, mais exécuter la requête plusieurs fois et faire la moyenne des temps.