Mi consulta se ejecuta más rápido la segunda vez, ¿cómo puedo detener eso?

Me postulo una consulta en Oracle 10 select A from B where C = D B cuenta con millones de registros y no hay ningún índice en CMi consulta se ejecuta más rápido la segunda vez, ¿cómo puedo detener eso?

La primera vez que corro que se tarda unos 30 segundos, la segunda vez que ejecute la consulta se tarda unos 1 segundo.

Obviamente está almacenando en caché algo y quiero que deje de hacerlo, cada vez que ejecuto la consulta quiero que tome 30 segundos, tal como se estaba ejecutando por primera vez.

estoy sobre simplificando el problema que estoy teniendo con el fin de hacer la pregunta legible.

Gracias

Fuente

2011-07-07 LoudNPossiblyWrong

¿Le importa explicar por qué quiere que funcione continuamente despacio? – Aducci

Respuesta probable: Ajuste y prueba del rendimiento – MatBailie

Cómo forzar un análisis detallado: http://oracle-randolf.blogspot.com/2009/02/how-to-force-hard-parse.html –

La eliminación de cachés para medir el rendimiento es posible pero muy difícil de manejar.

Una medida muy buena para el seguimiento del rendimiento logrado de los esfuerzos de ajuste es contar el número de bloques leídos durante la ejecución de la consulta. Uno de la manera más sencilla de hacerlo es utilizando sqlplus con AUTOTRACE, así:

set autotrace traceonly 
<your query>

salidas

... 
Statistics 
---------------------------------------------------------- 
      0 recursive calls 
      0 db block gets 
      1 consistent gets 
      0 physical reads 
      0 redo size 
     363 bytes sent via SQL*Net to client 
     364 bytes received via SQL*Net from client 
      4 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
      1 rows processed

El número de bloques de leer, ya sea desde la caché o desde el disco, es consistent gets.

Otra forma en que se ejecuta la consulta con el aumento de las estadísticas es decir con la indirecta gather_plan_statistics y luego mirar el plan de consulta de la caché del cursor:

auto autotrace off 
set serveroutput off 
<your query with hint gather_plan_statistics> 
select * from table(dbms_xplan.display_cursor(null,null,'typical allstats'));

El número de bloques leídos se emite en la columna buffers.

--------------------------------------------------------------------------------------------------------------------- 
| Id | Operation  | Name   | Starts | E-Rows | Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | 
--------------------------------------------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |    |  3 |  |  1 (100)|   |  3 |00:00:00.01 |  3 | 
| 1 | SORT AGGREGATE |    |  3 |  1 |   |   |  3 |00:00:00.01 |  3 | 
| 2 | INDEX FULL SCAN| ABCDEF   |  3 | 176 |  1 (0)| 00:00:01 | 528 |00:00:00.01 |  3 | 
---------------------------------------------------------------------------------------------------------------------

Fuente

2011-07-07 14:48:47

interesante, pero creé un índice compuesto en columnas que estoy usando en una función analítica, quiero ver si es efectivo este índice. ¿Puedo usar lo que describes para este efecto? thx – LoudNPossiblyWrong

sí, cada parte del plan de consulta aparecerá con su costo asociado. Eso incluye su índice compuesto si no ocurre nada inesperado. Una cosa inesperada podría ser que su índice no se usa. –

Ver este question ...

Muestra cómo borrar las memorias caché para datos y planes de ejecución, sino que también se expande de si es una buena idea o no.

Fuente

2011-07-07 14:16:48 MatBailie

-2

Te puede ayudar a

http://www.mssqltips.com/tip.asp?tip=1360

PUNTO DE CONTROL;
GO DBCC DROPCLEANBUFFERS;
GO

Fuente

2011-07-07 14:36:55

** Otra solución ** –

EXEC sys.sp_configure N'max server memory (MB) ', N'2147483646' GO RECONFIGURE WITH OVERRIDE GO (El tamaño depende de usted) –

Base de datos incorrecta ... No ayudará al OP demasiado en Oracle. (Mire las etiquetas en la pregunta) – derobert

La respuesta obvia es que cada caso de prueba para ejecutar la consulta varias veces, y tirar el primer resultado.

No es fácil replicar por completo las condiciones de la primera ejecución de la consulta, debido a las diversas memorias caché involucradas: algunas son cachés de Oracle (cursor, buffer, etc.); algunos son SO (caché de disco, dependiendo de la configuración de Oracle); algunos son hardware (SAN, RAID, disco).

Reiniciar el servidor de la base de datos antes de cada prueba probablemente se acerque bastante a las condiciones consistentes.

Fuente

2011-07-07 14:45:16 derobert

¿No sería el primer resultado el más preciso? – EvilTeach

En realidad, ¿no sería el primer resultado el menos preciso? Si lo ejecutó 100 veces, y el primero también 30 y el resto tomó 1, creo, en términos de experiencia del usuario, que ese valor de 30 es bastante inexacto. –

Mi consulta se ejecuta más rápido la segunda vez, ¿cómo puedo detener eso?

Respuesta

Cuestiones relacionadas