Explicación de los 7 principales eventos de espera de Oracle

Los eventos de espera de Oracle son estadísticas que un proceso o hilo del servidor incrementa cuando espera a que se complete una operación para continuar su procesamiento.

A continuación se explican algunos de los eventos de espera más comunes de Oracle.

Buffer ocupado espera

Este evento se produce cuando una sesión quiere acceder a un bloque de base de datos en la caché del búfer pero no puede porque el búfer está ocupado.

En términos sencillos: Imagina que tienes una videoconsola especial que sólo puede usar una persona a la vez.

Si quieres jugar y otra persona ya lo está utilizando, tienes que esperar a que termine.

En Oracle, el "búfer" es como esa consola de videojuegos: guarda datos importantes en la memoria.

Cuando una tarea quiere utilizar una parte de esos datos (un bloque de base de datos) pero ya está ocupado siendo utilizado por otra persona, la tarea tiene que esperar.

Esta espera se llama "espera de búfer ocupado".

Gracias, eso está mucho más claro. Vamos a centrarnos específicamente en buffer ocupado espera y cómo resolverlos.

🔍 ¿Qué es buffer ocupado espera?

• Este evento de espera se produce cuando varias sesiones intentan acceder al mismo bloque de datos en la caché del búferpero el bloque es actualmente ocupado (ya sea leída en la caché o modificada por otra sesión).
• Es un tema de discordia en el capa de caché del búferno es un problema de disco.

🛠 Causas y soluciones para buffer ocupado espera

1️⃣ Contención de bloques calientes (demasiadas sesiones en el mismo bloque)

• Ejemplo: Muchas sesiones actualizan o leen el mismo pequeño conjunto de bloques (por ejemplo, inserciones en el mismo bloque de tabla o actualizaciones de las mismas filas).
• Arregla:
  • Aumentar FREELISTAS / GRUPOS DE FREELISTAS (para tablespaces no-ASSM) para repartir las inserciones en más bloques.
  • Pasar a ASSM (Automatic Segment Space Management) para evitar cuellos de botella en las listas libres.
  • Particionar la tabla o utilizar partición hash para distribuir los datos en varios bloques.
  • Reconstruir índices o distribuir los datos de forma más uniforme.

2️⃣ Deshacer la contención de segmento

• Causa: Múltiples usuarios actualizando datos utilizando los mismos bloques de segmento de deshacer.
• Arregla:
  • Aumentar el número de segmentos de deshacer (establecer un valor más alto para _undo_autotune o ajustar el tamaño del tablespace de deshacer).
  • Revisar la configuración de retención de deshacer.

3️⃣ Contención de secuencias e índices

• Causa: Las inserciones rápidas en tablas con claves secuenciales (como los campos ID) pueden provocar bloqueos en caliente de los índices.
• Arregla:
  • Utilice índices de clave inversa.
  • Utilice índices particionados hash o índices mundiales.
  • Implementar secuencias en caché (CREAR SECUENCIA ... CACHÉ 1000).

4️⃣ Cargas de trayecto directo o LMD alto

• Causa: Inserciones simultáneas en la ruta directa u operaciones masivas frecuentes.
• Arregla:
  • Utilice APPEND consejos sabiamente.
  • Escalone los trabajos por lotes para evitar la concurrencia.
  • Asegúrese de que el paralelismo no sea demasiado agresivo.

5️⃣ Memoria intermedia inadecuada

• Causa: SGA insuficiente, lo que provoca la sustitución frecuente de bloques y la relectura desde el disco.
• Arregla:
  • Aumentar DB_CACHE_SIZE.
  • Utilice Gestión automática de memoria (AMM) o Gestión automática de memoria compartida (ASMM) bien afinado.

📝 Cómo diagnosticar la causa exacta

SELECT event, p1 "File#", p2 "Block#", p3 "Class#",
       COUNT(*) AS waits
FROM v$session_wait
WHERE event = 'buffer busy waits'
GROUP BY event, p1, p2, p3
ORDER BY waits DESC;

👉 Usa esto para encontrar el fichero# y bloque# causando la espera, entonces:

SELECT segment_name, segment_type
FROM dba_extents
WHERE file_id = &File#
AND &Block# BETWEEN block_id AND block_id + blocks - 1;

Esto te dice qué objeto (tabla/índice) es responsable.

✅ Resumen de las acciones:

Esperas libres en el búfer

Este evento se produce principalmente cuando un proceso servidor está intentando leer un nuevo búfer en la caché de búferes, pero hay demasiados búferes anclados o sucios y, por lo tanto, no están disponibles para su reutilización.

La sesión envía mensajes a DBWR y luego espera a que DBWR cree búferes libres escribiendo los búferes sucios en el disco.

En términos sencillos: Imagina que tienes una estantería de juguetes completamente llena.

Ahora, quieres ponerle un juguete nuevo, pero no hay sitio porque todos los lugares están ocupados por juguetes con los que se está jugando o que hay que limpiar primero.

Perfecto, sumerjámonos en esperas libres en el búfer específicamente, basándose en el evento de espera que mencionó del artículo.

🔍 ¿Qué es esperas libres en el búfer?

• Este evento se produce cuando una sesión necesita un búfer libre en la caché de búferespero no hay ninguno disponible porque:
  1. En DBWR (escritor de bases de datos) aún no ha escrito los búferes sucios en el disco para liberar espacio.
  2. El sistema está generando bloques sucios más rápido de lo que DBWR puede vaciarlos.

Indica una cuello de botella de escritura: la base de datos quiere reutilizar los buffers, pero aún no están libres.

🛠 Causas y soluciones para esperas libres en el búfer

1️⃣ E/S de disco lenta

• Causa: DBWR no puede escribir bloques sucios lo suficientemente rápido como para liberar búferes debido al lento rendimiento del disco.
• Arregla:
  • Mover archivos de datos a discos más rápidos (por ejemplo, SSD).
  • Equilibre la E/S repartiendo los datos entre varios discos o grupos de discos ASM.
  • Revisar y optimizar el Subsistema de E/S (ajuste SAN/NAS).

2️⃣ Rendimiento insuficiente del escritor de bases de datos

• Causa: Demasiados pocos procesos DBWR para manejar el volumen de bloques sucios.
• Arregla:
  • Aumentar el número de Procesos de DB Writer usando: DB_WRITER_PROCESSES = . (En los sistemas OLTP, varios DBWR ayudan a repartir la carga de escritura).

3️⃣ Caché demasiado pequeña

• Causa: La caché de búferes (SGA) es demasiado pequeña para manejar la carga de trabajo, lo que provoca una frecuente acumulación de búferes sucios.
• Arregla:
  • Aumentar DB_CACHE_SIZE (o utilizar la gestión automática de memoria (AMM/ASMM)).
  • Revisar los ratios de aciertos de la caché del buffer usando: SELECT name, value FROM v$sysstat WHERE name LIKE '%buffer cache%';

4️⃣ Alto volumen de búferes sucios

• Causa: Los picos repentinos de DML (actualizaciones/inserciones masivas) llenan la caché de bloques sucios más rápido de lo que pueden escribirse.
• Arregla:
  • Optimice las sentencias DML para reducir los cambios de bloque.
  • Utilice Cargas directas (sugerencia APPEND) para que las inserciones grandes eviten la caché del búfer.
  • Reparta los LMD pesados en el tiempo o prográmelos durante las horas de menor tráfico.

5️⃣ Comprobación y Rehacer

• Causa: Un ajuste ineficiente de los puntos de control puede retrasar el reciclaje de los búferes.
• Arregla:
  • Ajuste los parámetros del punto de control: FAST_START_MTTR_TARGET.
  • Aumentar tamaño del archivo de registro para evitar puntos de control demasiado frecuentes.
  • Compruebe si hay cuellos de botella de E/S en el archivo de registro de rehacer.

📝 Cómo diagnosticar esperas libres en el búfer

1. Consulta las sesiones en curso: SELECT * FROM v$session_wait WHERE event = 'free buffer waits';
2. Comprueba el rendimiento de E/S (tiempos medios de escritura): SELECT fichero#, avg_time, writes FROM v$filestat;
3. Comprueba las estadísticas de búfer sucio: SELECT * FROM v$sysstat WHERE name LIKE '%dirty%';

✅ Cuadro recapitulativo:

👉 Este es un cuello de botella en el sistema-la solución suele pasar por tanto el hardware (discos, memoria) como la configuración (DBWR, caché, redo).

Lectura secuencial de archivos de base de datos

Este evento muestra una espera de un proceso en primer plano mientras se realiza una lectura secuencial de la base de datos.

La E/S se emite generalmente como una única petición de E/S al SO; la espera se bloquea hasta que la petición de E/S se completa.

En términos sencillos: Imagina que tienes un libro ilustrado favorito, pero está guardado en una estantería alta.

Cuando quieres ver una página concreta, le pides a un amigo que la coja por ti.

Mientras tu amigo busca la página, tú te sientas y esperas a que vuelva con ella.

Genial, centrémonos ahora en archivo db lectura secuencialque es uno de los eventos de espera más comunes de Oracle.

🔍 ¿Qué es archivo db lectura secuencial?

• Esta espera se produce cuando Oracle realiza lecturas de un solo bloque del disco a la memoria.
• Es típico de:
  • Consulta de índices (especialmente índices B-tree)
  • Acceso fila por fila mediante acceso a la tabla por ROWID
  • Bucles anidados

Se denomina "secuencial" porque Oracle lee un bloque cada vez (no en trozos de varios bloques).

🛠 Causas y soluciones para archivo db lectura secuencial

1️⃣ SQL ineficaz (malos planes de ejecución)

• Causa: Consultas que utilizan índices de forma ineficiente o que acceden a los datos fila por fila de forma innecesaria.
• Arregla:
  • Utilice EXPLICAR EL PLAN para revisar las rutas de consulta.
  • Considere añadir índices que faltan o reescribir SQL mejorar las vías de acceso.
  • Utilice métodos de unión con prudencia: evite los bucles anidados innecesarios.

👉 Comprobar plan de ejecución:

EXPLAIN PLAN FOR <your SQL>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

2️⃣ Índices no selectivos

• Causa: Se siguen utilizando índices que recuperan demasiadas filas (cardinalidad baja).
• Arregla:
  • Elimine o evite el uso de índices que no filtren bien.
  • Considere índices de mapa de bits para columnas de baja cardinalidad (sistemas OLAP/DSS).

3️⃣ Índices que faltan

• Causa: Se evitan los escaneos completos de tablas, pero sin índices adecuados Oracle vuelve a las lentas lecturas de un solo bloque.
• Arregla:
  • Añadir índices apropiados para reducir el acceso a la tabla por ROWID.
  • Implementar índices compuestos para múltiples condiciones de filtrado.

4️⃣ Almacenamiento lento (cuello de botella de E/S de disco)

• Causa: Aunque las consultas sean eficientes, un almacenamiento lento puede provocar tiempos de espera elevados.
• Arregla:
  • Mover datos a discos más rápidos (SSD).
• Utilice Franjas ASM o una distribución adecuada de los discos.

👉 Comprueba la entrada/salida del archivo:

SELECT file#, avg_time, reads, writes
FROM v$filestat
ORDER BY avg_time DESC;

5️⃣ Memoria caché insuficiente (demasiada E/S física)

• Causa: Los errores en la caché del búfer provocan más lecturas de disco.
• Arregla:
  • Aumentar DB_CACHE_SIZE.
  • Revisar y afinar Gestión automática de memoria (AMM/ASMM).

👉 Comprueba la eficiencia de la caché:

SELECT name, value FROM v$sysstat
WHERE name IN ('physical reads', 'consistent gets', 'db block gets');

6️⃣ Objetos calientes (acceso frecuente a los mismos bloques)

• Causa: Ciertos objetos (índices o tablas pequeñas) son accedidos repetidamente, causando un churn del buffer.
• Arregla:
  • Utilice MANTENER el buffer pool para tablas o índices pequeños de uso frecuente: ALTER TABLE tu_tabla STORAGE (BUFFER_POOL KEEP);

📝 Consultas de diagnóstico rápido

1. Encuentre sesiones en espera:

SELECT sid, p1 file#, p2 block#, p3 blocks
FROM v$session_wait
WHERE event = 'db file sequential read';

2. Asigna el archivo# y el bloque# al objeto:

SELECT owner, segment_name, segment_type
FROM dba_extents
WHERE file_id = &file#
AND &block# BETWEEN block_id AND block_id + blocks - 1;

✅ Cuadro recapitulativo:

👉 Esta espera es normal para sistemas OLTP, pero los valores excesivos señalan problemas.

Archivo de base de datos de lectura dispersa

Este es el mismo tipo de evento que "db file sequential read", excepto que Oracle leerá múltiples bloques de datos.

Las lecturas multibloque se utilizan normalmente en los escaneos de tablas completas.

El nombre "lectura dispersa" hace referencia al hecho de que se leen varios bloques en los búferes de bloques de la base de datos que están "dispersos" por toda la memoria.

En términos sencillos: Imagina que tienes un libro de ilustraciones enorme y quieres hojear muchas páginas rápidamente.

En lugar de pedir una página cada vez (como en una lectura secuencial), pides un montón de páginas a la vez.

Estas páginas pueden proceder de distintas partes del libro, de modo que, cuando llegan, están esparcidas o "dispersas" por toda la mesa de lectura.

Excelente, abordemos archivo db lectura dispersa ahora.

🔍 ¿Qué es archivo db lectura dispersa?

• Este evento de espera se produce cuando Oracle realiza lecturas multibloque, típicamente asociado con:
  • Escáneres de mesa completa
  • Escaneado rápido de índices completos
• Se llama "dispersos" porque los bloques leídos del disco se dispersan por los búferes de memoria en lugar de colocarse secuencialmente (por lo tanto, los datos se dispersan en la caché del búfer).

Es habituales en los entornos de almacén de datos (DSS) pero debe reducirse al mínimo en los sistemas OLTP.

🛠 Causas y soluciones para archivo db lectura dispersa

1️⃣ Exploraciones innecesarias de toda la mesa

• Causa: Las consultas acceden a tablas completas en lugar de utilizar índices.
• Arregla:
  • Añadir índices apropiados (árbol B o mapa de bits).
  • Utilice EXPLICAR EL PLAN para garantizar la índice se utiliza realmente.
  • Compruebe si estadísticas del optimizador no disponibles o antiguas y reunirlos:
    EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCOTT', tabname => 'EMP');

2️⃣ Escaneados completos de mesa pequeña

• Causa: Oracle a menudo elige escaneos completos para mesas muy pequeñaslo que suele estar bien.
• Arregla:
  • Esto es normal y normalmente ningún problema a menos que la frecuencia sea extrema.

3️⃣ Ejecución paralela de consultas

• Causa: Las consultas paralelas en tablas grandes hacen que varias sesiones lean bloques dispersos de forma concurrente.
• Arregla:
  • Optimice grado de paralelismo utilizando POLÍTICA DE GRADOS PARALELOS y LÍMITE_GRADO_PARALELO.
  • Considere partición tablas grandes para minimizar la necesidad de escaneos completos paralelos.

4️⃣ Diseño ineficaz de las consultas (filtrado deficiente)

• Causa: Las consultas recuperan grandes conjuntos de resultados sin cláusulas WHERE selectivas.
• Arregla:
  • Perfeccione condiciones WHERE para reducir las filas devueltas.
  • Evite **consultas SELECT *** innecesarias.
  • Consulte lógica de aplicación que desencadena estas lecturas.

5️⃣ Rendimiento del sistema o del almacenamiento

• Causa: Incluso cuando son necesarios escaneos completos (por ejemplo, trabajos por lotes), E/S de disco lenta puede agravar esta espera.
• Arregla:
  • Asegúrese el subsistema de disco es rápido (considere SSD, E/S paralela, striping ASM).
  • Aumentar DB_FILE_MULTIBLOCK_READ_COUNT (aunque Oracle lo sintoniza automáticamente en las versiones modernas).

📝 Consultas de diagnóstico rápido

1. Identificar las sesiones en espera:

SELECT sid, p1 file#, p2 block#, p3 blocks
FROM v$session_wait
WHERE event = 'db file scattered read';

2. Mapa al objeto:

SELECT owner, segment_name, segment_type
FROM dba_extents
WHERE file_id = &file#
AND &block# BETWEEN block_id AND block_id + blocks - 1;

3. Encuentre los principales SQL causantes de escaneos completos:

SELECT sql_id, executions, buffer_gets, disk_reads
FROM v$sql
WHERE sql_id IN (SELECT sql_id FROM v$session WHERE event = 'db file scattered read')
ORDER BY disk_reads DESC;

✅ Cuadro recapitulativo:

👉 Consejo clave:

• archivo db lectura dispersa en un OLTP sistema suele ser un bandera roja → centrarse en indexación y ajuste de consultas.
• En DSS/BI entornos, a menudo es comportamiento esperado pero aún debe ser eficiente.

Espera en cola

Esta métrica representa el número total de esperas por segundo que se produjeron durante una conversión u obtención en cola porque la obtención en cola se aplazó.

En términos sencillos: Imagina que tienes un tobogán especial en el parque infantil que todo el mundo quiere usar.

Cuando llegas al tobogán y ves que otra persona ya está en él, tienes que esperar tu turno.

Cada vez que esperas porque el tobogán está ocupado, es como una "espera en cola".

Perfecto, desglosemos poner en cola espera en Oracle y cómo resolverlos.

🔍 ¿Qué son poner en cola ¿Espera?

• En poner en cola es un tipo de cierre Oracle utiliza para controlar el acceso simultáneo a los recursos (como filas, tablas, índices o estructuras internas).
• Cuando una sesión no puede obtener inmediatamente un bloqueo necesarioespera un evento en cola de espera.

👉 Las esperas en cola suelen verse como:

enqueue: <type> - <details>

Por ejemplo:

• enq: TX - contención de bloqueo de fila
• esq: TM - contención
• esq: UL - contención

🛠 Tipos comunes de cola de espera y soluciones

1️⃣ enq: TX - contención de bloqueo de fila (Más común)

• Causa: Una sesión es modificar una línea y otro intenta acceder a la misma fila → conduce a bloqueos TX (transacción).
• Arregla:
  • Identificar y eliminar la contención a nivel de aplicación (la misma fila se actualiza con demasiada frecuencia).
  • Implementar transacciones cortas: comprometen antes y evitan largas transacciones ociosas que mantienen bloqueos.
  • Considere cambios en la lógica de la aplicación a serializar acceso a datos sensibles (colas, contadores).

👉 Diagnóstico:

SELECT * FROM v$lock WHERE type = 'TX';

Encontrar sesión de bloqueo:

SELECT blocking_session, sid, serial#, wait_class, seconds_in_wait
FROM v$session
WHERE blocking_session IS NOT NULL;

2️⃣ esq: TM - contención (LMD sobre objetos)

• Causa: Típico de cuestiones clave en el extranjero o bloqueos de metadatos.
• Arregla:
  • Asegúrese de que las claves externas están indexadas (para evitar bloqueos de tabla en eliminaciones/actualizaciones de padre-hijo).
  • Evitar lo innecesario DDL mientras se ejecuta DML.

3️⃣ enq: TX - contención de índice (Hot Index Blocks)

• Causa: Inserciones de alto valor monetario en el mismo índice bloque de hojas (por ejemplo, identificadores secuenciales).
• Arregla:
  • Utilice índices de clave inversa.
  • Utilice índices globales con partición hash para extender los insertos.

4️⃣ esq: SQ (Contención de secuencia)

• Causa: Múltiples sesiones utilizando el misma secuencia sin caché → hotspot.
• Arregla:
  • Definir secuencias con CACHE y/o NOORDER: CREATE SEQUENCE my_seq CACHE 1000 NOORDER;

5️⃣ enq: UL (Bloqueos definidos por el usuario)

• Causa: Aplicación mediante DBMS_LOCK o colas personalizadas.
• Arregla:
  • Revisar y optimizar lógica de aplicación utilizando estas cerraduras.

6️⃣ enq: HW (Contención de la marca de pleamar)

• Causa: Alta frecuencia de los insertos provocan el crecimiento del segmento.
• Arregla:
  • Preasignar espacio utilizando: ALTER TABLE mi_tabla ALLOCATE EXTENT;
  • Considere insertos paralelos o la difusión de datos.

📝 Consultas de diagnóstico para esperas en cola de espera

1. Sesiones en espera en colas:

SELECT sid, event, p1raw, p2, p3
FROM v$session
WHERE event LIKE 'enq%';

2. Bloqueador contra camarero:

SELECT sid, blocking_session, event, wait_class
FROM v$session
WHERE blocking_session IS NOT NULL;

3. Descodificación detallada de colas (opcional):

SELECT chr(bitand(p1, -16777216) / 16777215) ||
       chr(bitand(p1, 16711680) / 65536) "Lock Type"
FROM v$session
WHERE event LIKE 'enq%';

✅ Cuadro recapitulativo:

👉 Consejo general:

• En la mayoría de los casos, las esperas en cola se deben a un diseño ineficiente de la aplicación o a la falta de índices.
• El ajuste a nivel de sistema (SGA, E/S) tiene poco efecto...es sobre todo SQL y correcciones lógicas.

Espacio del búfer de registro

Espera a que haya espacio en el búfer de registro porque estamos escribiendo en el búfer de registro más rápido de lo que lgwr puede escribirlo.

En términos sencillos: Imagina que tienes un cuaderno especial en el que apuntas notas rápidamente.

Hay un ayudante, LGWR, cuyo trabajo consiste en tomar tus notas y escribirlas en un libro grande y seguro.

Si escribes notas demasiado deprisa y el bloc se llena antes de que tu ayudante pueda despejar algo de espacio, tendrás que hacer una pausa y esperar hasta que vuelva a haber sitio.

Este tiempo de espera se denomina espera de "espacio de búfer de registro".

Excelente elección: centrémonos en espacio de búfer de registro esperas en Oracle, que son menos comunes pero críticas cuando aparecen.

🔍 ¿Qué es espacio de búfer de registro?

• Este evento de espera ocurre cuando:
  • Oracle intenta copiar rehacer entradas del búfer de registro (SGA) a la registros de rehacer en líneapero hay no hay espacio libre en el búfer de registro porque los datos de rehacer aún no se han escrito en el disco.

Señala un cuello de botella entre procesos de usuario que generan rehacer y LGWR (Log Writer) descargándolo a los redo logs.

🛠 Causas y soluciones para espacio de búfer de registro

1️⃣ Rehacer registros en disco lento

• Causa: La LBTR no puede escribir datos de rehacer en el disco lo suficientemente rápido.
• Arregla:
  • Lugar redo logs en el almacenamiento más rápido disponible (preferiblemente SSD o discos dedicados).
  • Utilice ASM con la configuración adecuada del grupo de discos para los redo logs.
  • Compruebe si latencia de almacenamiento.

👉 Comprueba la E/S del archivo de registro:

SELECT * FROM v$logfile;

2️⃣ Buffer de Redo Log pequeño (LOG_BUFFER)

• Causa: En memoria El búfer de registro es demasiado pequeñocausando esperas frecuentes cuando muchas sesiones generan rehacer.
• Arregla:
  • Aumentar el LOG_BUFFER tamaño en el SPFILE o PFILE. ALTER SYSTEM SET LOG_BUFFER = SCOPE=SPFILE;
  • Las versiones modernas de Oracle lo ajustan automáticamente, pero el ajuste manual puede seguir siendo útil para los sistemas de repetición intensiva.

👉 Comprueba el tamaño actual del búfer de registro:

SHOW PARAMETER log_buffer;

3️⃣ LBVR insuficiente o lenta

• Causa: La Proceso de la Legión no está a la altura del volumen de rehacer.
• Arregla:
  • Asegúrese LBTR no está compitiendo con otros procesos por la CPU.
  • En RAC: verifique que LGWR y canales de E/S están correctamente distribuidos.

4️⃣ Alta Generación de Rehacer (Demasiado COMMIT o DML)

• Causa: Tasa muy alta de commits, DML o trabajos por lotes que generan grandes volúmenes de rehacer.
• Arregla:
  • Utilice confirmaciones por lotes en lugar de frecuentes commits por fila.
  • Optimizar las operaciones DML para reducir rehacer (operaciones a granel, cargas directas por vía cuando sea factible).
  • Considere NOLOGGING opciones para cargas de datos cuando no se requiere recuperabilidad.

👉 Identificar las sesiones que generan rehacer:

SELECT sid, serial#, value
FROM v$sesstat s, v$statname n
WHERE s.statistic# = n.statistic#
AND n.name = 'redo size'
ORDER BY value DESC;

5️⃣ Redo Log Files Demasiado Pequeño (Cambios Frecuentes de Log)

• Causa: Archivos de registro de rehacer pequeños → cambios de registro frecuentes → mayor presión de la LGWR → contención de búfer.
• Arregla:
  • Aumentar tamaño del archivo redo log: ALTER DATABASE ADD LOGFILE SIZE 1G;
  • Objetivo cambia de registro no más de 10-15 veces por hora en OLTP.

👉 Compruebe la frecuencia del interruptor de registro:

SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour, COUNT(*)
FROM v$log_history
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
ORDER BY hour DESC;

📝 Pasos rápidos de diagnóstico

1. Comprueba las sesiones en espera en el búfer de registro:

SELECT sid, event, wait_time, seconds_in_wait
FROM v$session
WHERE event = 'log buffer space';

2. Comprueba el tamaño de rehacer y la tasa de commit:

SELECT name, value FROM v$sysstat
WHERE name IN ('redo size', 'user commits');

3. Comprueba el rendimiento de escritura de la LGWR:

SELECT name, value FROM v$sysstat
WHERE name LIKE '%log file%';

✅ Cuadro recapitulativo:

👉 Notas clave:

• espacio de búfer de registro las esperas son poco frecuente en sistemas bien configurados.
• Las correcciones casi siempre implican hardware (discos más rápidos), configuración (tamaños de registro, búfer) y ajuste de aplicaciones (patrones DML/commit).

Sincronización de archivos de registro

Es la espera para que la LGWR escriba en los archivos de registro de rehacer.

En términos sencillos: Imagina que estás jugando a un juego en el que cada movimiento que haces debes anotarlo en un diario especial para recordarlo.

Hay un amigo llamado LGWR cuyo trabajo es anotar cada movimiento.

Si haces un movimiento y luego tienes que esperar porque tu amigo todavía está escribiendo el movimiento anterior en el diario, eso es una espera de "sincronización de archivos de registro".

Significa que estás en pausa hasta que la LGWR termine de anotar tu movimiento en los archivos de registro.

Gran elección.sincronización de archivos de registro es uno de los acontecimientos de espera comunes e importantes en bases de datos Oracle, especialmente en sistemas OLTP. Desglosémoslo por completo.

🔍 ¿Qué es sincronización de archivos de registro?

• Este evento de espera se produce cuando una sesión compromete una transacción y debe esperar a que el LGWR (Log Writer) escriba los datos de rehacer en el archivo de registro de rehacer y confirmar que está bien guardado.
• Sólo después de que se confirme esta escritura se puede confirmar la confirmación al usuario.

👉 En resumen:
Compromete → LGWR escribe → Usuario espera → sincronización de archivos de registro

🛠 Causas y soluciones para sincronización de archivos de registro

1️⃣ Commits frecuentes (Commit Flooding)

• Causa: La aplicación realiza commits después de cada fila o con demasiada frecuencia.
• Arregla:
  • Implementar confirmaciones por lotes: confirmar después de procesar varias filas en lugar de después de cada fila.
  • Revisar la lógica de la aplicación para reducir las confirmaciones innecesarias.

👉 Diagnóstico:

SELECT name, value FROM v$sysstat WHERE name = 'user commits';

2️⃣ Escrituras lentas de Redo Log (cuello de botella de E/S de disco)

• Causa: Los discos que contienen los archivos redo log son lentos o están sobrecargados, lo que retrasa las escrituras de la LGWR.
• Arregla:
  • Colocar los registros de rehacer en almacenamiento de alta velocidad (SSD, Flash).
  • Aislar los redo logs de los datafiles y otros discos ocupados.
  • Utilice ASM con redundancia y striping.

👉 Comprueba el rendimiento del redo log:

SELECT name, value FROM v$sysstat WHERE name LIKE 'redo writes%';

3️⃣ Archivos de Redo Log pequeños (demasiados conmutadores)

• Causa: Frecuente interruptores de registro provocando retrasos y una mayor actividad de la Legión.
• Arregla:
  • Aumentar tamaño del archivo redo log para reducir el número de interruptores por hora.
  • Compruebe si registrar tormentas de conmutación durante las horas punta.

👉 Comprueba el historial del interruptor de registro:

SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour, COUNT(*)
FROM v$log_history
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
ORDER BY hour DESC;

4️⃣ Cuello de botella en la CPU que afecta a la LGWR

• Causa: La LGWR compite por la CPU con otros procesos, lo que provoca retrasos en la confirmación.
• Arregla:
  • Consulte Uso de la CPU y garantizar que la Legión de la Buena Voluntad no pase hambre.
  • En sistemas altamente concurrentes, considere añadir más CPU u optimizar la concurrencia de la aplicación.

👉 Comprueba las principales esperas de procesos en segundo plano:

SELECT p.spid, s.sid, s.event, s.wait_time
FROM v$session s, v$process p
WHERE s.paddr = p.addr AND s.sid IN (SELECT blocking_session FROM v$session WHERE blocking_session IS NOT NULL);

5️⃣ Alta generación de repeticiones (demasiado DML)

• Causa: Grandes volúmenes de DML generando excesivo redo, abrumando LGWR.
• Arregla:
  • Optimizar DML: utilizar procesamiento a granelminimizar rehacer innecesario.
  • Utilice NOLOGGING cuando sea seguro (cargas ETL, índices).

👉 Comprobar rehacer generado por transacción:

SELECT name, value FROM v$sysstat WHERE name LIKE '%redo%';

📝 Diagnóstico rápido para sincronización de archivos de registro

1. Comprobar sesiones en espera:

SELECT sid, event, seconds_in_wait, state
FROM v$session
WHERE event = 'log file sync';

2. Revisar las estadísticas de commit y redo a nivel de sistema:

SELECT name, value FROM v$sysstat
WHERE name IN ('user commits', 'redo size', 'log file sync waits');

3. Si utiliza AWR o StatspackBusca:

• sincronización de archivos de registro tiempo medio de espera (debería ser idealmente < 1 msproblemático si > 10 ms).

✅ Tabla resumen de soluciones:

👉 Principales conclusiones:

• Alta sincronización de archivos de registro → indica tiempo de respuesta problemas, a menudo perceptibles para los usuarios finales.
• Está estrechamente vinculada a Rendimiento de la LGWR, subsistema redo y patrones de confirmación de aplicaciones.

Espero que te haya sido útil.