Cómo deshabilitar la memoria caché de Oracle para las pruebas de rendimiento

Question

Estoy tratando de probar la utilidad de una nueva tabla de resumen para mis datos.

Así que he creado dos procedimientos para recuperar los datos de un cierto intervalo, cada uno usando una fuente de tabla diferente. Entonces, en mi aplicación de consola C#, llamo a uno u otro. El problema comienza cuando quiero repetir esto varias veces para tener un buen patrón de tiempo de respuesta.

que tiene algo como esto: 1199,84,81,81,81,81,82,80,80,81,81,80,81,91,80,80,81,80

Probablemente mi Oracle 10g está haciendo un almacenamiento en caché inadecuado.

¿Cómo puedo resolver esto?

Answer 1

EDIT: Ver este thread on asktom, que describe cómo y por qué no hacer esto.

Si se encuentra en un entorno de prueba, usted puede poner su línea de tablas y de nuevo en línea:

ALTER TABLESPACE <tablespace_name> OFFLINE; 
ALTER TABLESPACE <tablespace_name> ONLINE; 

O puede probar

ALTER SYSTEM FLUSH BUFFER_CACHE; 

pero de nuevo sólo en el entorno de prueba.

Cuando prueba en su sistema "real", los tiempos que obtiene después de la primera llamada (los que usan datos en caché) pueden ser más interesantes, ya que tendrá datos en caché. Llame al procedimiento dos veces y solo tenga en cuenta los resultados de rendimiento que obtiene en las ejecuciones posteriores.

Answer 2

Probablemente mi Oracle 10g está realizando un almacenamiento en memoria caché inadecuado.

En realidad, parece que Oracle está haciendo un caché completamente apropiado. Si estas tablas se van a usar mucho, entonces esperaría tenerlas en caché la mayor parte del tiempo.

edición

En un comentario sobre la respuesta de Pedro Luis dijo

lavado antes de la llamada Tengo algunas resultados interesantes como: 1370.354.391.375.352.511.390.375.326.335.435.334.334.328.337.314.417.377.384.367.393.

Estos hallazgos son "interesantes" porque el enjuague significa que las llamadas tardan un poco más que cuando las filas están en la memoria caché pero no tan largas como la primera. Esto es casi seguro porque el servidor ha almacenado los registros físicos en su caché física. La única manera de evitar eso, ejecutar de verdad contra un caché vacío es reiniciar el servidor antes de cada prueba.

También puede aprender a ajustar las consultas correctamente. Comprender how the database works es un buen comienzo. Y EXPLAIN PLAN es una mejor ayuda de ajuste que el reloj de pared.Find out more.