Buffer Busy Wait y Leer por otra Sesión en Oracle
Cuando una sesión accede y marca en memoria un bloque en la cache de buffers, ninguna otra sesión puede marcar ese mismo bloque hasta que la primera sesión lo libere. Si otra sesión intenta acceder al mismo bloque mientras está marcado, queda en espera por un evento llamado Buffer Busy Wait. La particularidad de este tipo de espera es que la contención ocurre a nivel de bloque; incluso si ambas sesiones quieren filas distintas del mismo bloque, compiten a nivel de bloque.
Los bloques Oracle pueden almacenar distintos tipos de información, por lo que la contención de bloques se clasifica en varias categorías: bloque de datos, cabecera de segmento de datos, cabecera de undo y bloque de undo. A continuación se describe el papel de cada tipo y las causas y soluciones típicas.
1) Bloque de datos
Son los bloques que contienen los datos de objetos. Las Buffer Busy Waits sobre bloques de datos pueden deberse a varias causas:
- Consultas mal optimizadas: aumentan el número de bloques leídos por sesión. Minimizar lecturas innecesarias reduce contención.
- Bloque caliente: un bloque con filas accedidas frecuentemente puede convertirse en cuello de botella. Optimizar diseño de datos y patrones de acceso es clave.
- Fallos frecuentes de cache en bloques calientes: si un bloque no está en la cache y dos sesiones lo necesitan, la segunda espera a que la primera lo traiga. En Oracle anteriores a la 10.1 esto se contabilizaba como Buffer Busy Wait; desde la 10.1 se reporta como Read by Other Session.
- Tamaño de bloque grande: bloques con más filas aumentan la probabilidad de accesos simultáneos. Para reducir contención se puede reconstruir el objeto con mayor PCTFREE o usar un tamaño de bloque menor; también considerar particionado o cambiar el diseño de índices.
- Contención de índice: en índices con hot blocks considerar particionado por hash o índices reverse para redistribuir filas entre bloques. Por ejemplo para reconstruir un índice como reverse se puede usar:
ALTER INDEX SALTEST.SPPA_INDX4 REBUILD REVERSE;
Para listar objetos con muchas esperas de buffer busy waits:
SELECT owner, object_name, l.object_type, SUM(value) buffer_busy_count, ROUND(SUM(value) * 100 / SUM(SUM(value)) OVER(), 2) pct FROM v$segment_statistics l WHERE statistic_name = 'buffer busy waits' AND value > 0 GROUP BY owner, object_name, l.object_type ORDER BY SUM(value) DESC;
2) Cabecera de segmento de datos
Cada segmento tiene un bloque cabecera que almacena metadatos como el high water mark y las listas de libres. La contención en esta cabecera puede producirse cuando se eliminan datos y se necesitan actualizar freelists, cuando se insertan datos y se aumenta el high water mark o cuando se asigna un nuevo extent. Buenas prácticas: particionar el segmento para multiplicar cabeceras y reducir contención, usar extents mayores para evitar asignaciones frecuentes y preferir tablespaces con ASSM en lugar de administración por freelists.
3) Cabecera de undo y bloque de undo
Si hay pocos segmentos de undo y muchos cambios concurrentes, puede haber contención en las cabeceras de undo, especialmente con gestión manual de undo. También ocurre si varias sesiones generan undo en el mismo bloque de undo. Soluciones: aumentar tamaño del tablespace de undo, mejorar el diseño de la aplicación para reducir generación excesiva de undo y balancear el número de segmentos de undo.
Para identificar bloques implicados en esperas buffer busy waits:
SELECT p1 FileNumber, p2 BlockNumber, p3 ReasonCode FROM v$session_wait WHERE event = 'buffer busy waits';
Y para localizar el segmento propietario del bloque:
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = &P1 AND &P2 BETWEEN block_id AND block_id + blocks - 1;
Leer por otra Sesión Read by Other Session
Si un bloque no está en la cache y dos sesiones lo necesitan, la segunda espera hasta que la primera complete la lectura desde disco y cargue el bloque en cache. Este tipo de espera se denomina Read by Other Session desde Oracle 10.1 en adelante. Consultas poco optimizadas o I/O de disco lento pueden hacer que esta espera consuma una porción significativa del tiempo de la base de datos.
Demostración práctica y recomendaciones
En un experimento con block size 2K y cache limitada se pueden provocar Buffer Busy Waits haciendo que dos sesiones actualicen alternadamente filas dentro del mismo conjunto de bloques. En los informes AWR esa contención aparece en la sección Segments by Buffer Busy Waits. Puntos clave para reducir estas esperas: optimizar consultas para leer menos bloques, rediseñar objetos y particionar cuando convenga, ajustar tamaño de bloque y PCTFREE, y usar índices apropiados como reverse o particionado por hash cuando haya hot spots.
Resumen
Buffer Busy Wait indica contención en un bloque ya presente en cache. Read by Other Session indica que una sesión espera a que otra complete la lectura desde disco y cargue el bloque en cache. El diseño de objetos, el tamaño de bloque, la estrategia de índices y la optimización de consultas son determinantes para mitigar estas esperas.
Sobre Q2BSTUDIO
En Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida para empresas que necesitan soluciones escalables y seguras. Además ofrecemos servicios de inteligencia artificial, ia para empresas y agentes IA para automatizar procesos y mejorar la toma de decisiones. Nuestra oferta incluye también ciberseguridad y pentesting para proteger entornos críticos y servicios cloud aws y azure para desplegar plataformas robustas y escalables. Si necesita una aplicación empresarial personalizada, visite nuestra página de desarrollo de aplicaciones y software multicanal aplicaciones a medida y si busca integrar soluciones de IA o servicios de inteligencia artificial para empresa consulte nuestro servicio de inteligencia artificial ia para empresas.
Palabras clave
aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.