Peter le dio la respuesta a la pregunta que hizo.
alter system flush shared_pool;
Esa es la afirmación que usaría para "eliminar declaraciones preparadas de la memoria caché".
(declaraciones preparadas no son los únicos objetos añade desde la piscina compartida, la declaración hace más que eso.)
Como indiqué en mi comentario anterior (en su pregunta), v$sql no es una tabla. Es una vista de rendimiento dinámico, una conveniente representación en forma de tabla de las estructuras de memoria interna de Oracle. Solo tiene el privilegio SELECT en las vistas de rendimiento dinámico, no puede eliminar filas de ellas.
al ras de la piscina y el tampón de caché compartida?
Lo siguiente no responde su pregunta directamente. En su lugar, responde una pregunta fundamentalmente diferente (y tal vez más importante):
¿Deberíamos normalmente purgar el grupo compartido y/o la memoria caché del búfer para medir el rendimiento de una consulta?
En resumen, la respuesta es no.
Creo que Tom Kyte aborda esta bastante bien:
http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html
http://www.oracle.com/technetwork/issue-archive/o43asktom-094944.html
<extracto>
En realidad, es importante que una herramienta de ajuste no hace eso. Es importante ejecutar la prueba, ignorar los resultados y luego ejecutarla dos o tres veces y promediar esos resultados. En el mundo real, la memoria caché del búfer nunca carecerá de resultados. Nunca.Cuando sintonice, su objetivo es reducir la E/S lógica (LIO), porque entonces la E/S física (PIO) se encargará sola.
Considere esto: Vaciar el grupo compartido y la memoria caché del búfer es aún más artificial que no descargarlos. La mayoría de la gente parece escéptica de esto, sospecho, porque va en contra de la sabiduría convencional. Te mostraré cómo hacer esto, pero no para que puedas usarlo para probar. Más bien, lo usaré para demostrar por qué es un ejercicio inútil y totalmente artificial (y por lo tanto conduce a suposiciones erróneas). Acabo de iniciar mi PC, y he ejecutado esta consulta en una gran mesa. I "vaciar" la caché del búfer y ejecutar de nuevo:
</extracto >
Creo que Tom Kyte es exactamente correcto. En términos de abordar el problema del rendimiento, no creo que "borrar el caché del plan de ejecución del oráculo" sea normalmente un paso para una evaluación comparativa confiable.
Vamos a abordar la preocupación sobre el rendimiento.
Nos dice que ha observado que la primera ejecución de una consulta lleva mucho más tiempo (~ 28 segundos) en comparación con las ejecuciones posteriores (~ 5 segundos), incluso cuando se vacía (todos los bloques de índice y datos) la memoria caché del buffer
Para mí, eso sugiere que el parse duro está haciendo un trabajo pesado. Es mucho trabajo o tiene muchas esperas. Esto puede ser investigado y ajustado.
Me pregunto si tal vez las estadísticas no existen, y el optimizador está gastando mucho tiempo recopilando estadísticas antes de preparar un plan de consulta. Esa es una de las primeras cosas que verificaría, que las estadísticas se recopilan en todas las tablas, índices y columnas indexadas a las que se hace referencia.
Si su consulta se une a un gran número de tablas, la CBO puede estar considerando una gran cantidad de permutaciones para la orden de unión.
Una discusión del seguimiento de Oracle está fuera del alcance de esta respuesta, pero es el siguiente paso.
Estoy pensando que son probablemente va a querer rastrear eventos 10053 y 10046.
Aquí hay un enlace a un "evento 10053" discusión de Tom Kyte usted puede encontrar útil:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
tangencialmente relacionado historia anecdótica re: el rendimiento de análisis dura
Hace unos años, vi una consulta que había transcurrido en términos de minutos en la primera ejecución, ejecuciones posteriores en términos de segundos. Lo que descubrimos fue que la gran mayoría del tiempo para el primer tiempo de ejecución se gastó en el análisis detallado.
Este problema de consulta fue escrito por un desarrollador de CrystalReports que inocentemente (¿ingenuamente?) Unió dos enormes vistas de informes.
Una de las vistas era una combinación de 62 tablas, la otra vista era una combinación de 42 tablas.
La consulta utilizó el optimizador basado en costos.El seguimiento reveló que no era el tiempo de espera, sino todo el tiempo de CPU dedicado a evaluar posibles rutas de combinación.
Cada una de las vistas de "informes" suministradas por el proveedor no era tan mala en sí misma, pero cuando dos de ellas se unieron, era terriblemente lenta. Creo que el problema fue la gran cantidad de permutaciones de unión que el optimizador estaba considerando. Hay un parámetro de instancia que limita el número de permutaciones consideradas por el optimizador, pero nuestra solución fue volver a escribir la consulta. La consulta mejorada solo se unió a la docena de tablas que realmente necesitaba la consulta. (La solución inmediata de corto plazo fue programar una ejecución de la consulta antes de la mañana, antes de ejecutar la tarea de generación de informes. Eso hizo que la generación de informes "más rápido", porque uso de la declaración ya preparada en el grupo compartido, evitando el análisis detallado.
El parche no era una solución real, simplemente trasladaba el problema a una ejecución preliminar de la consulta, cuando el tiempo de ejecución largo no era 'notado.
Nuestro siguiente paso probablemente habría sido implementar un "esquema almacenado" para la consulta, para obtener un plan de consulta estable.
Por supuesto, la reutilización de sentencias (evitando el análisis detallado, utilizando variables de vinculación) es el patrón normativo en Oracle. Mejora el rendimiento, la escalabilidad, yada, yada, yada.
Este incidente anecdótico puede ser completamente diferente al problema que está observando.
HTH
v $ sql no es realmente una tabla, es una vista de rendimiento dinámico, y no, no puede eliminar filas de ella. – spencer7593