La lectura de un bloque es el acceso típico por índice, y la media por lectura mide el almacenamiento. Una media alta apunta al disco o al camino hasta él, pero la distribución dice si el problema es de todas las lecturas o de unas pocas.
Síntomas
En el Diagnóstico aparece uno de estos hallazgos (LEITURA_LENTA), con el nombre del evento al final del título:
- Lectura de bloque único lenta en db file sequential read, cuando la media por lectura está muy por encima de lo que entrega un almacenamiento sano. El texto recuerda que un disco rápido o flash responde por debajo de 1 ms y pide revisar el almacenamiento y la cola de I/O.
- Lectura de bloque único por encima de lo esperado en db file sequential read, cuando la media supera lo esperado sin llegar a tanto.
El texto trae la media en milisegundos, el número de lecturas y el porcentaje del tiempo total, por ejemplo Promedio de 12,5 ms por lectura en 4 lecturas (4,9% del tiempo total). El enlace es Ver distribución de latencia, o Ver en el perfil cuando el evento no tiene tabla de latencia.
La gravedad es alta en el primer título y media en el segundo. Cuando el evento pesa poco en el tiempo total, el hallazgo sale como baja, solo como registro: la media es mala, pero acelerar el almacenamiento casi no cambia el tiempo de esta operación.
Se aplica a las esperas de lectura de un bloque a la vez, como db file sequential read y cell single block physical read. Cada evento lento genera su propio hallazgo.
Causa
El plan decide cuántas lecturas hace la sesión; el almacenamiento decide cuánto demora cada una. Una media alta suele venir de:
- almacenamiento sobrecargado en el período, con cola de I/O: otras sesiones, un backup, un proceso nocturno por lotes u otro sistema en el mismo storage;
- lecturas que van al disco en lugar de caer en la caché del storage o en el flash (en Exadata, el bloque no estaba en la flash cache);
- un problema en el camino de I/O: multipath, controladora, red del storage;
- pocas lecturas muy lentas que suben la media, con la mayoría rápidas.
Solución
- Mire la distribución antes que la media. En la distribución de latencia del evento y en Lecturas, con rangos para disco (cortes de 5 ms a 1 s) y para SSD (cortes de 15 µs a 10 ms), compruebe si todas las lecturas son lentas o si unas pocas lentas pesan más.
- Revise el almacenamiento en el Período del trace: tiempo de servicio y cola de los discos, por ejemplo con
iostat, y qué más se ejecutaba en el mismo storage.iostat -x 5 - En la base de datos, compare con la latencia que ve toda la instancia en el mismo evento. Los números son acumulados desde el inicio de la instancia.
select wait_time_milli, wait_count from v$event_histogram where event = 'db file sequential read' order by wait_time_milli; - Reduzca el número de lecturas, que suele rendir más que acelerar el disco: vea muchas lecturas de bloque único.
- Si el problema es del storage, lleve la media, los rangos y el período del informe a quien lo administra.
Cómo confirmar
Después del cambio en el almacenamiento o en el plan, genere un trace nuevo de la misma operación. En la fila del evento en el perfil, Media (s) debe bajar, cerca de lo que entrega el almacenamiento de la base de datos (lecturas trae la referencia de disco y de SSD), y el hallazgo desaparece. Compare también los rangos en Lecturas: la parte lenta debe reducirse.
En el informe
En el informe de ejemplo, las 2 lecturas de db file sequential read tienen una media de 0,000650 s (0,65 ms), sin hallazgo. Los enlaces abren las secciones del ejemplo:
- Diagnóstico: el hallazgo y el enlace Ver distribución de latencia.
- Perfil, fila db file sequential read: Ocurrencias, Media (s) y Máx (s).
- Distribución de latencia del evento: cuántas lecturas caen en cada rango.
- Lecturas, rangos de disco y rangos de SSD: rangos más finos para todas las esperas de lectura.
- Objetos con más tiempo de espera: en qué tabla o índice se gastó el tiempo.