systemdba

En entornos con Oracle GoldenGate, es común asumir que un Replicat integrado garantiza consistencia total al reiniciarse después de una falla. Sin embargo, cuando se utiliza la opción NOFILTERDUPTRANSACTIONS, ese supuesto cambia de forma importante.

Este artículo explica por qué un Replicat puede fallar con errores de tipo DELETE row not found después de reiniciarse, aun cuando la información en el destino es consistente, y cómo interpretar correctamente este comportamiento.

El comportamiento esperado del Replicat Integrated

El Replicat integrado aplica transacciones completas dentro del Inbound Server del destino.

• Si el proceso falla antes del COMMIT, la transacción se revierte automáticamente.
• Si el COMMIT ya ocurrió, los cambios permanecen en la base de datos destino.

Esto garantiza integridad transaccional, pero no implica que el Replicat siempre esté perfectamente alineado con su último checkpoint.

El problema: desfase entre checkpoint y datos aplicados

Después de una caída, puede ocurrir lo siguiente:

1. El Replicat aplica y confirma una transacción en el destino.
2. El proceso falla antes de actualizar su checkpoint.
3. Al reiniciarse, vuelve a leer esa misma transacción desde el trail.

Aquí es donde normalmente GoldenGate protege el flujo: detecta que la transacción ya fue aplicada y la ignora.

Pero esa protección desaparece si se usa NOFILTERDUPTRANSACTIONS.

El efecto de NOFILTERDUPTRANSACTIONS

Cuando esta opción está habilitada, el Replicat:

• No filtra transacciones duplicadas.
• Reintenta aplicar todo lo que encuentra en el trail, incluso si ya fue aplicado.

Esto provoca errores como:

• DELETE: la fila ya no existe → row not found
• INSERT: duplicado → violación de PK
• UPDATE: fila inexistente → error de actualización

En realidad, el problema no es inconsistencia de datos, sino reejecución de operaciones ya confirmadas.

Caso típico del error en DELETE

Escenario común:

1. Se ejecuta un DELETE y se confirma en el destino.
2. El Replicat falla antes de actualizar su checkpoint.
3. Se reinicia con NOFILTERDUPTRANSACTIONS.
4. Intenta ejecutar el mismo DELETE nuevamente.
5. La fila ya no existe → error.

Este comportamiento es esperado bajo esta configuración.

Implicaciones operativas

Este escenario indica que:

• El destino está ligeramente adelantado respecto al checkpoint del Replicat.
• No hay corrupción lógica en los datos.
• El error es consecuencia de reejecución, no de pérdida de información.

Estrategias de solución

1. Saltar la operación puntual

Aplicar temporalmente un manejo de error (REPERROR) para permitir continuar:

• Ignorar el error específico (por ejemplo, fila no encontrada).
• Reanudar el Replicat.
• Restaurar la configuración normal.

2. Reubicar el checkpoint (recomendado)

• Identificar el último CSN aplicado en el destino.
• Iniciar el Replicat después de ese punto (AFTERCSN).

Esto evita reprocesar transacciones ya confirmadas.

3. Revisar el uso de NOFILTERDUPTRANSACTIONS

En la mayoría de escenarios OLTP estándar:

• No es necesario usar esta opción.
• Puede generar más problemas que beneficios tras fallas.

El uso de NOFILTERDUPTRANSACTIONS elimina el mecanismo de protección contra transacciones duplicadas en GoldenGate. Como resultado, después de una falla, el Replicat puede intentar reejecutar operaciones ya aplicadas, generando errores como DELETE row not found.

Este comportamiento no indica corrupción de datos, sino un desfase entre el checkpoint y el estado real del destino. La solución consiste en alinear correctamente el punto de reinicio o manejar temporalmente los errores, evitando depender permanentemente de configuraciones que ignoren inconsistencias.