Este evento wait indica
que se está ejecutando un requerimiento de lectura en disco. Este evento wait
se diferencia del evento wait "db file scattered read" en que un
"sequential read" lee datos en bloques de memoria contigua (a
diferencia de un "scattered read" el cual lee múltiple bloques y los
distribuye en diferentes bloques en la SGA).
Generalmente
un "sequential read" representa la lectura de un bloque simple,
aunque es posible que se presenten sequential reads para más de un bloque. Este
evento wait también puede representar la lectura de los headers de los
datafiles.
Es
importante notar que en ocasiones un requerimiento de lectura de Oracle al
Sistema Operativo puede ser resuelto desde el cache de file system del Sistema
Operativo.
El
IO es una actividad normal de modo tal que el interés se debe centrar en el IO
innecesario o lento. Si el tiempo en espera por IO es significativo entonces se
debe determinar que segmentos de Oracle exigen ir más a disco. Para esto se
deben analizar las sesiones "Tablespace IO" and "File IO"
de los reportes de ADDM para obtener información de que tablespaces o datafiles
se están realizando más requerimientos de IO, y obtener indicadores de
velocidad del subsistema de IO. Si el tiempo en espera por lecturas es
significativo entonces puede ser útil determinar en qué segmentos son los que
se están realizando estos requerimientos.
El
siguiente query es útil para determinar que sesiones están realizando reads y
hacer trace de estas para ver si los requerimientos de IO son los esperados.
SELECT sid, total_waits, time_waited
FROM v$session_event
WHERE event='db file sequential read'
and total_waits>0
ORDER BY 3,2 ;
También
se debe analizar lo siguiente:
También
se debe analizar lo siguiente:
-
Statements with high DISK_READS
-
Sessions with high "physical reads"
Afinar
este evento wait implica mejorar sentencias; usar discos más veloces, aumentar
el tamaño de la memoria, etc.
- Uso de un “unselective index”.
Las
siguientes recomendaciones pueden ser útiles:
ü Compruebe que los índices
se utilizan correctamente.
ü Reconstruir indexes con un factor alto de clustering.
ü Revisar los planes de ejecución de la Sentencias SQL que acceden a datos a través de índices
ü Un buffer cache de mayor tamaño puede ser de ayuda. Pero debe incrementarse de manera controlada.
ü Un problema que puede afectar las tasas de I/O es la manera como están agrupados físicamente los datos.
ü Un preordenamiento o reorganización de la DATA puede ayudar a atacar esta situación.
ü Analizar si Partitioning se puede utilizar para reducir la cantidad de datos que se requieren buscar.
ü Puede ser de utilidad colocar los archivos que incurren en Index Scans frecuentes en discos que estén configurados con "OS file system cache". Esto permitirá que algunas solicitudes de lectura de Oracle sean satisfechas por la caché del sistema operativo en lugar de realizar una operación de Disk I/O real.
Referirse a las notas de
Oracle:
Si DBA_INDEXES.CLUSTERING_FACTOR
del índice se acerca al número de bloques en la tabla, entonces la mayoría de
las filas de la tabla están clasificadas (deseable), Sin embargo, si el
factor de agrupación se acerca al número de filas de la tabla, esto significa
que las filas de la tabla se ordenan al azar y por lo tanto se requiere más I/O
para completar la operación. Se puede mejorar el factor de agrupación del
índice mediante la reconstrucción de la tabla para que las filas se ordenen de
acuerdo con la llave del índice y volver a generarlo a partir de este.
Los parámetros de inicialización OPTIMIZER_INDEX_COST_ADJ y OPTIMIZER_INDEX_CACHING pueden influir en el optimizador para favorecer la operación de bucles anidados y elegir una ruta de acceso de índice durante un escaneo completo de tabla.
Los parámetros de inicialización OPTIMIZER_INDEX_COST_ADJ y OPTIMIZER_INDEX_CACHING pueden influir en el optimizador para favorecer la operación de bucles anidados y elegir una ruta de acceso de índice durante un escaneo completo de tabla.
No hay comentarios.:
Publicar un comentario