El tiempo de lectura es el número de lecturas por la media de cada una. Cuando la media es normal y el tiempo es alto, el problema es la cantidad: el plan visita demasiados bloques para las filas que devuelve.
Síntomas
En el Diagnóstico aparece el hallazgo Muchas lecturas de bloque único (db file sequential read) (MUITAS_LEITURAS), con el nombre del evento entre paréntesis. El texto dice cuántas lecturas suman qué parte del tiempo total, por ejemplo 25.000 lecturas suman el 32,4% del tiempo total, sugiere revisar si el plan lee demasiados bloques y termina con Ver distribución de latencia, o Ver en el perfil cuando el evento no tiene tabla de latencia.
El hallazgo aparece cuando una espera de lectura de un bloque a la vez, como db file sequential read o cell single block physical read, ocupa una parte grande del tiempo total, cualquiera que sea la media por lectura. La gravedad es siempre media. Puede aparecer junto con lectura lenta: uno habla de la cantidad, el otro de la velocidad.
Causa
Causas frecuentes:
- índice poco selectivo, que devuelve muchos ROWID y lleva a una visita a la tabla por cada uno (
TABLE ACCESS BY INDEX ROWID); - NESTED LOOPS sobre muchas filas, con una búsqueda en el índice de la tabla interna por cada fila de la externa;
- índice con clustering factor alto: filas vecinas en el índice repartidas en muchos bloques de la tabla;
- el mismo SQL ejecutado una vez por cada fila de un bucle (fila a fila en PL/SQL);
- buffer cache pequeño para el volumen de datos, con el mismo bloque leído del disco más de una vez.
Solución
- Encuentre la sentencia. En Sentencias principales por componente, abra el grupo del evento de lectura y vea las sentencias que más leyeron.
- En el detalle de la sentencia, en Dónde gasta el plan, vea la operación que concentra el tiempo, con las columnas PR (lecturas físicas) y Filas del plan. Muchas lecturas para pocas filas indican un acceso poco selectivo.
- Encuentre el objeto en Objetos con más tiempo de espera. En la consola, el obj# abre la página del objeto, con consultas listas como Tabla: índices y las columnas de cada uno e Índice: detalles, tabla y columnas.
- Corrija el acceso: un índice con las columnas del filtro, en el orden correcto; HASH JOIN en lugar de NESTED LOOPS cuando el volumen es grande; estadísticas actualizadas cuando la estimación es errónea (estimación de filas errónea).
- Si el mismo SQL se ejecuta una vez por fila, cambie el bucle por procesamiento en conjunto (fila a fila en PL/SQL).
- Si la relectura del mismo bloque pesa (en Lecturas, Primera lectura y relectura del mismo bloque), evalúe el tamaño del buffer cache.
Cómo confirmar
Genere un trace nuevo de la misma operación después del cambio. En la fila del evento en el perfil, las Ocurrencias deben bajar; en la sentencia corregida, también la columna PIO de Sentencias SQL. El hallazgo desaparece cuando el evento deja de ocupar una parte grande del tiempo total.
En la primera ejecución después del cambio, parte de los bloques puede venir del disco porque todavía no está en la caché. Compare mediciones hechas en la misma condición: las dos con la caché fría, o las dos con la caché ya caliente.
En el informe
En el informe de ejemplo, db file sequential read suma el 18,5% del tiempo total en 2 lecturas, sin hallazgo. El informe del caso 2, de un trace real, tiene este hallazgo (Diagnóstico del caso 2). Los enlaces de abajo abren las secciones del ejemplo:
- Diagnóstico: el hallazgo y el enlace a la latencia del evento.
- Perfil, fila db file sequential read: Ocurrencias y % del total.
- Sentencias principales por componente, grupo del evento: las sentencias que más leyeron.
- Plan de la sentencia #1: la operación
TABLE ACCESS BY INDEX ROWIDdestacada. - Objetos con más tiempo de espera y Lecturas: el objeto leído y la relectura de los mismos bloques.