supprimer plan exécution [Résolu]

[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]

Envoyé par CssFaxien

- 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 :

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]

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

[CssFaxien]

Envoyé par Ahmed AANGOUR

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

[Ahmed AANGOUR]

Envoyé par 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

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 :

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]

Envoyé par CssFaxien

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.