Estos serían los planes de consulta que el SQL Navigator 5 me indica que tomará Oracle:
SQL Statement from editor:
Cita:
Código SQL:
Ver originalSELECT SUM(1) logid
FROM LOG_SISTEMA WHERE
(TIEMPO BETWEEN
TO_DATE('07/08/2012 12:00:00', 'DD/MM/YYYY hh24:mi:ss') AND
TO_DATE('07/08/2012 12:04:59', 'DD/MM/YYYY hh24:mi:ss'))
------------------------------------------------------------
Cost=2,64018716311899E-308
SELECT STATEMENT RULE
(3) SORT AGGREGATE
(2) NON-UNIQUE INDEX RANGE SCAN LOG4NET.TIEMPO_IDX [Not Analyzed]
Cita: SQL Statement from editor:
Código SQL:
Ver originalSELECT SUM(1) logid
FROM LOG_SISTEMA WHERE
(TIEMPO
< TO_DATE('07/08/2012 12:04:59', 'DD/MM/YYYY hh24:mi:ss'))
------------------------------------------------------------
Cost=2,64018716311899E-308
SELECT STATEMENT RULE
(3) SORT AGGREGATE
(2) NON-UNIQUE INDEX RANGE SCAN LOG4NET.TIEMPO_IDX [Not Analyzed]
El detalle del index full scan ha sido bastante revelador, a lo que hay que sumar el hecho de que no existe ningún momento en el día o la semana en que esa tabla y sus índices estén sin uso (se han llegado a computar 1200 entradas/segundo a la taba de logs, en 7*24*365).
Con eso ya tenemos una idea de lo que nos está pasando.
Ahora hemos modificado el SP en el segmento de esa consulta para sortear el problema.
Veremos cómo resulta al entrar en producción.