Peter vous a donné la réponse à la question que vous avez posée.
alter system flush shared_pool;
C'est l'instruction que vous utiliseriez pour "supprimer les instructions préparées du cache".
(déclarations préparées ne sont pas les seuls objets vidées de la piscine commune, la déclaration fait plus que cela.)
Comme je l'ai indiqué dans mon commentaire précédent (sur votre question), v$sql n'est pas une table. C'est une vue dynamique des performances, une représentation pratique des tables de la structure de la mémoire interne d'Oracle. Vous n'avez que le privilège SELECT sur les vues de performances dynamiques, vous ne pouvez pas en supprimer les lignes.
la flush piscine partagée et cache tampon?
Ce qui suit ne répond pas directement à votre question. Au lieu de cela, il répond à un fondamentalement différent (et peut-être plus important) question:
Faut-il rincer normalement la piscine commune et/ou le cache de mémoire tampon pour mesurer la performance d'une requête?
En bref, la réponse est non.
Je pense que Tom Kyte aborde ce joli bien:
http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html
http://www.oracle.com/technetwork/issue-archive/o43asktom-094944.html
<extrait>
En fait, il est important qu'un outil de réglage pas cela. Il est important d'exécuter le test, d'ignorer les résultats, puis de l'exécuter deux ou trois fois et de faire la moyenne de ces résultats. Dans le monde réel, le cache tampon ne sera jamais dépourvu de résultats. Jamais.Lorsque vous réglez, votre objectif est de réduire les E/S logiques (LIO), car alors les E/S physiques (PIO) prendront soin d'elles-mêmes. Considérez ceci: vider le pool partagé et le cache tampon est encore plus artificiel que de ne pas les vider. Je suppose que la plupart des gens semblent sceptiques, car cela va à l'encontre des idées reçues. Je vais vous montrer comment faire, mais pas si vous pouvez l'utiliser pour tester. Je vais plutôt l'utiliser pour démontrer pourquoi c'est un exercice futile et totalement artificiel (et donc conduit à des hypothèses erronées). Je viens de démarrer mon PC, et j'ai lancé cette requête sur une grande table. I "vider" le cache de mémoire tampon et l'exécuter à nouveau:
</extrait >
Je pense que Tom Kyte est tout à fait exact. En ce qui concerne le problème de performance, je ne pense pas que «l'effacement du cache du plan d'exécution d'Oracle» est normalement une étape pour une analyse comparative fiable.
Abordons la question des performances. Vous nous dites que vous avez observé que la première exécution d'une requête prend beaucoup plus de temps (~ 28 secondes) par rapport aux exécutions suivantes (~ 5 secondes), même lors du vidage (tous les blocs d'index et de données) le cache tampon.
Pour moi, cela suggère que le dure l'analyse fait un peu de levage lourd. C'est beaucoup de travail ou il y a beaucoup d'attentes. Cela peut être étudié et réglé. Je me demande si les statistiques sont inexistantes, et l'optimiseur passe beaucoup de temps à collecter des statistiques avant de préparer un plan de requête. C'est l'une des premières choses que je vérifie, que les statistiques sont collectées sur toutes les tables référencées, les index et les colonnes indexées.
Si votre requête rejoint un grand nombre de tables, l'OCB peut envisager un grand nombre de permutations pour l'ordre de jointure.
Une discussion sur le traçage d'Oracle dépasse la portée de cette réponse, mais c'est l'étape suivante.
Je pense que vous allez probablement vouloir retracer les événements 10053 et 10046.
Voici un lien vers une discussion « événement 10053 » par Tom Kyte peut vous être utile:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
histoire anecdotique qu'accessoirement liés re: performance hard parse
Il y a quelques années, j'ai vu une requête qui s'était écoulée en termes de MINUTES lors de la première exécution, les exécutions suivantes en termes de secondes. Ce que nous avons trouvé était que la grande majorité du temps pour le premier temps d'exécution était consacré à l'analyse dure.
Cette requête de problème a été écrite par un développeur de CrystalReports qui, innocemment (naïvement?), A joint deux vues de rapport volumineuses.
Une des vues était une jointure de 62 tables, l'autre vue était une jointure de 42 tables.
La requête a utilisé l'Optimiseur basé sur les coûts.Le suivi a révélé que ce n'était pas le temps d'attente, c'était tout le temps passé par le processeur à évaluer les chemins de jointure possibles. Chacune des vues «reporting» fournies par le fournisseur n'était pas trop mauvaise en soi, mais lorsque deux d'entre elles étaient jointes, c'était terriblement lent. Je crois que le problème était le grand nombre de permutations de jointure que l'optimiseur considérait. Il existe un paramètre d'instance qui limite le nombre de permutations prises en compte par l'optimiseur, mais notre solution consistait à réécrire la requête. La requête améliorée n'a rejoint que la douzaine de tables dont la requête avait réellement besoin. Le correctif initial immédiat de «band aid» à court terme consistait à planifier une exécution de la requête plus tôt dans la matinée, avant la génération de la tâche de génération de rapports. l'utilisation de l'instruction déjà préparée dans le pool partagé, en évitant l'analyse complète
Le correctif d'aide de bande n'était pas une vraie solution, il a juste déplacé le problème à une exécution préliminaire de la requête, quand le long temps d'exécution wasn
Notre prochaine étape aurait probablement été de mettre en œuvre un "outline stocké" pour la requête, afin d'obtenir un plan de requête stable
Bien entendu, la réutilisation d'instructions (en évitant l'analyse syntaxique, à l'aide de variables de liaison) est le modèle normatif d'Oracle. Il améliore les performances, l'évolutivité, yada, yada, yada.
Cet incident anecdotique peut être entièrement différent du problème que vous observez.
HTH
v $ sql n'est pas vraiment une table, c'est une vue dynamique des performances, et non, vous ne pouvez pas en effacer les lignes. – spencer7593