Operación diaria y escenarios de avería de Oracle GoldenGate (Microservices 21c / 23ai)
OracleNivel: AvanzadoDuración: 5 min (comprobación) – 2 horas (actualización, añadir una tabla)Runbook de operación diaria y recuperación ante averías para una replicación GoldenGate Microservices ya instalada (para la instalación, consulte la guía de instalación de GoldenGate). Si no está seguro de qué hacer, empiece por 'Comprobación de estado y retraso': el diagnóstico de solo lectura le lleva al escenario adecuado — Extract y Replicat en ABEND (report, discard, errores OGG-xxxxx), añadir una tabla con datos a la replicación (SCN coherente + AFTERCSN), quitar una tabla, resincronizar una sola tabla, limpieza de trail (Purge Trail), reposicionar Extract desde un SCN, actualización de versión/parche y continuidad de Extract tras un switchover/failover de Data Guard en el origen. Cada escenario sigue el esquema diagnóstico → red de seguridad → aplicación → verificación.
Topología: Servidor de origen (deployment de origen, Integrated Extract, Distribution Path) + servidor de destino (deployment de destino, Parallel Replicat)
Escenarios
- Comprobación de estado y retraso (¿va todo bien?) — Solo lectura: Service Manager y los microservicios, INFO ALL, lag, STATS, retraso del heartbeat, estado del capture en la base de datos y ggserr.log; no se cambia nada. Si no está seguro de qué hacer, empiece aquí.
- Extract ABENDED (detenido con error) — El Extract del origen está en ABENDED o se reinicia una y otra vez: la causa (conexión, archived log que falta, log mining, privilegios, disco) se identifica por el error OGG-xxxxx del archivo de report, se corrige y el Extract se inicia de nuevo desde donde se quedó. La base de datos de origen no se ve afectada; el retraso se acumula.
- Replicat ABENDED (no puede aplicar en el destino) — El Replicat del destino no pudo aplicar una transacción: la tabla, la operación y el error se identifican a partir de los archivos report y discard; los datos se corrigen o se omiten temporalmente con REPERROR, y el Replicat se reinicia desde donde se detuvo. El destino permanece abierto; el retraso se acumula.
- Añadir una tabla con datos a la replicación (carga inicial + AFTERCSN) — Añade a una replicación en marcha, sin parada, una tabla existente que ya contiene datos: ADD TRANDATA, expdp/impdp con un SCN coherente y un Replicat aparte que aplica solo los cambios de esta tabla posteriores a ese SCN (AFTERCSN). Las demás tablas siguen replicándose.
- Quitar una tabla de la replicación — La tabla dejará de replicarse: TABLEEXCLUDE en el Extract (o eliminar la línea TABLE), MAPEXCLUDE en el Replicat y, si es necesario, DELETE TRANDATA. Los procesos se reinician brevemente.
- Resincronizar una sola tabla (resync) — Los datos de una tabla en el destino se han desviado del origen (cambio manual, error omitido, carga inicial incompleta): la tabla se vuelve a cargar desde el origen con un SCN coherente y un Replicat temporal aplica los cambios posteriores a ese SCN. Las demás tablas no se ven afectadas.
- Los archivos de trail llenan el disco: limpieza (Purge Trail) — El directorio de trail crece o el disco está a punto de llenarse: se comprueba qué archivos se están leyendo y se define una tarea Purge Trail (el equivalente de PURGEOLDEXTRACTS en Classic) con USECHECKPOINTS; en caso de emergencia, los archivos ya leídos se borran manualmente.
- Reposicionar Extract en un SCN concreto — Hay un SCN desde el que quiere que Extract vuelva a empezar (pérdida de trail, punto de inicio erróneo, vuelta atrás en el destino): se arranca desde un nuevo archivo de trail con ALTER EXTRACT … SCN y ETROLLOVER. Los mismos datos pueden llegar al destino por segunda vez.
- Actualización de versión / parche de GoldenGate (Microservices) — Paso a una nueva versión o parche de GoldenGate: out-of-place (instalar un nuevo home y trasladar Service Manager y los deployments al nuevo home con REST) o in-place con OPatch. Extract/Replicat se detienen brevemente; la vuelta atrás consiste en volver al home anterior.
- Mantener Extract en marcha tras un switchover/failover de Data Guard en el origen — Se ha producido un switchover o un failover en la base de datos de origen; Extract debe conectarse a la nueva primary y continuar desde su checkpoint: se comprueban la conexión (credential alias/servicio), el estado del capture, HANDLEDLFAILOVER y una posible divergencia de datos.
Antes de empezar
- GoldenGate Microservices instalado como en la guía de instalación: en el origen, Integrated Extract … y Distribution Path … en el deployment …; en el destino, Parallel Replicat … en el deployment …; credential alias ggsrc/ggsrc_pdb (origen) y ggtgt (destino).
- Dispone de la contraseña de oggadmin de ambos deployments (los pasos la solicitan; no se escribe en los scripts).… Para la carga inicial están preparados la contraseña de SYSTEM en ambas PDB y el directory OGG_DP (…) de la instalación.…
- El servicio systemd de Service Manager (OracleGoldenGate) está en ejecución en ambos servidores.
- Hay abierto un registro de cambio/ventana de mantenimiento: …Extract, Distribution Path y Replicat están detenidos durante la actualización; el retraso se acumula y se reabsorbe al terminar…al rebobinar Extract, las mismas transacciones pueden llegar al destino por segunda vez; se ha acordado un plan de colisiones con el responsable de la aplicación…las operaciones omitidas con REPERROR faltarán en el destino; el responsable de negocio lo ha aprobado…los procesos se reinician brevemente….
Fases de la guía
- Estado: procesos, retraso y servicios (solo lectura) — Comprobar Service Manager y los puertos de los microservicios · Mostrar los procesos de origen, el retraso del Extract y el Distribution Path (origen) · Mostrar los procesos de destino y el retraso del Replicat (destino) · Medir el retraso de extremo a extremo con el heartbeat (destino) · Comprobar el estado del capture y los archived logs necesarios en la base de datos de origen (origen) · Revisar el log de errores (origen) …
- 1. Diagnóstico: ¿por qué se detuvo Extract? — Mostrar el estado del Extract y el error del report (origen) · Comprobar el estado del capture y los archived logs en la base de datos (origen)
- 2. Red de seguridad — Hacer copia de seguridad de los archivos de parámetros, checkpoint y report (origen)
- 3. Aplicación: corregir la causa y arrancar Extract — Restaurar los archived logs que faltan desde el backup de RMAN (origen) · Corregir la causa · Arrancar Extract y supervisarlo (origen)
- 4. Verificación y seguimiento — Verificar que el retraso se reabsorbe (origen) · Prevenir la causa raíz (origen)
- 1. Diagnóstico: ¿en qué operación se detuvo Replicat? — Mostrar el estado del Replicat, el report y el archivo discard (destino) · Comparar la fila con error en el destino y en el origen
- 2. Red de seguridad — Hacer copia de los archivos de parámetros, checkpoint y report (destino)
- 3. Aplicación: corregir los datos e iniciar el Replicat — Corregir los datos en el destino · Desviar temporalmente el error al archivo discard: REPERROR (destino) · Iniciar el Replicat (destino)
- 4. Verificación y seguimiento — Verificar que el Replicat avanza (destino) · Quitar el REPERROR temporal (destino)
- 1. Diagnóstico: ¿es la tabla apta para la replicación? — Analizar la tabla en el origen (origen) · Mostrar el estado del supplemental logging (origen) · Comprobar la tabla en el destino (destino)
- 2. Red de seguridad — Hacer copia de los archivos de parámetros y checkpoint (origen) · Hacer copia de los archivos de parámetros y checkpoint (destino) · Hacer copia de la tabla de destino (destino)
- 3. Aplicación: cargar la tabla e iniciarla con su propio Replicat — Activar el supplemental logging a nivel de tabla (origen) · Excluir la tabla del Replicat principal: MAPEXCLUDE (destino) · Quitar del Replicat principal la línea MAP explícita de la tabla (destino) · Añadir la tabla al Extract (origen) · Añadir un Replicat nuevo solo para esta tabla (destino) · Exportar la tabla con un SCN consistente (origen) …
- 4. Verificación y seguimiento — Comparar el número de filas (origen) · Comprobar el número de filas y el Replicat nuevo (destino)
- 1. Diagnóstico: ¿dónde está definida la tabla? — Mostrar dónde aparece la tabla en los archivos de parámetros y su supplemental logging (origen) · Mostrar la asignación de la tabla en el Replicat (destino)
- 2. Red de seguridad — Hacer copia de los archivos de parámetros y checkpoint (origen) · Hacer copia de los archivos de parámetros y checkpoint (destino)
- 3. Aplicación: quitar la tabla del Extract y del Replicat — Quitar la tabla del Extract (origen) · Esperar a que se apliquen los registros que quedan en el trail (destino) · Quitar la tabla del Replicat (destino) · Quitar la línea MAP de la tabla (destino) · Quitar el supplemental logging a nivel de tabla (origen)
- 4. Verificación — Verificar que la tabla ya no se procesa (origen)
- 1. Diagnóstico: ¿cuánto espacio ocupan los trails y quién los lee? — Mostrar el directorio y los archivos de trail (origen) · Mostrar el directorio de trail y la posición que lee el Replicat (destino)
- 2. Aplicación: definir la tarea Purge Trail — Definir la tarea Purge Trail en el deployment de origen · Definir la tarea Purge Trail en el deployment de destino
- 3. Emergencia: borrar manualmente los archivos de trail ya leídos — Borrar los archivos de trail ya leídos
- 1. Diagnóstico: ¿se puede volver al SCN? — Mostrar la posición actual del Extract (origen) · Comprobar el primer SCN del capture y los archived logs (origen)
- 2. Red de seguridad — Hacer copia de seguridad de los archivos de parámetros, checkpoint y report (origen)
- 3. Aplicación: posicionar el Extract en el SCN — Detener el Extract, posicionarlo en el SCN e iniciarlo desde un archivo de trail nuevo (origen)
- 4. Verificación — Verificar que el Extract avanza desde la nueva posición (origen) · Vigilar las colisiones en el destino (destino)
- 1. Diagnóstico: versión actual y preparación — Registrar la versión actual, los parches y los procesos (origen) · Registrar la versión actual, los parches y los procesos (destino)
- 2. Red de seguridad — Hacer copia de los directorios del deployment y de Service Manager (origen) · Hacer copia de los directorios del deployment y de Service Manager (destino)
- 3. Aplicación: detener los procesos y actualizar — Detener los procesos de forma ordenada (origen) · Detener los procesos de forma ordenada (destino) · Instalar el nuevo GoldenGate home (origen) · Instalar el nuevo GoldenGate home (destino) · Pasar Service Manager y el deployment al nuevo home (origen) · Aplicar el parche con OPatch (origen) …
- 4. Verificación — Iniciar los procesos y verificar la versión (origen) · Iniciar los procesos y verificar la versión (destino) · Vuelta atrás (si hace falta)
- 1. Diagnóstico: la nueva primary y la conexión del Extract — Comprobar el rol y el estado del capture de la nueva primary (nueva primary) · Mostrar el estado del Extract y los credential alias (origen)
- 2. Red de seguridad — Hacer copia de seguridad de los archivos de parámetros, checkpoint y report (origen)