Este artículo ofrece una visión general de la replicación de bases de datos Oracle. Trata conceptos, arquitecturas, pasos de implementación y prácticas operativas recomendadas. Aprenderá cómo se relaciona la replicación con el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). Se describen los métodos fundamentales: Data Guard, GoldenGate, vistas materializadas y opciones heredadas. Asimismo, se explica el monitoreo, las alertas y la seguridad en la replicación.
¿Qué es la replicación de Oracle Database?
Oracle captura los cambios realizados en una base de datos fuente y los aplica en una o más bases de datos destino. Admite un modo sincrónico, que espera la confirmación del commit, y un modo asíncrono, que envía los cambios sin esperar. El modo sincrónico garantiza prácticamente cero pérdida de datos, pero introduce latencia; el modo asíncrono reduce la latencia, aunque implica un riesgo mínimo de brechas de datos en caso de fallo. Oracle utiliza transporte de registros redo, minería de registros (log mining) o registros de vistas materializadas, según el método elegido. Los modelos de coherencia varían: inmediato para el modo sincrónico y eventual para el modo asíncrono.
Replicación está vinculada al RPO (Objetivo de punto de recuperación) y al RTO (Objetivo de tiempo de recuperación). Los modos sincrónicos permiten un RPO casi nulo. El modo asíncrono equilibra el RPO con la distancia de red. Usted elige según las necesidades empresariales y la infraestructura disponible. Asimismo, debe planificar el RTO: la velocidad con la que puede poner en funcionamiento una réplica. Estos objetivos orientan la selección del método y su configuración.
¿Por qué debería replicar la base de datos Oracle?
La replicación satisface prioridades fundamentales de operaciones: recuperación ante desastres, alta disponibilidad, equilibrio de carga y continuidad del negocio. También facilita los análisis y las migraciones.
Recuperación ante desastres y RPO/RTO: La replicación almacena copias en ubicaciones remotas. En caso de fallo, se cambia al sistema de espera. La replicación sincrónica produce una pérdida mínima de datos (RPO casi nulo). La replicación asíncrona es adecuada para ubicaciones a larga distancia con un RPO moderado. El RTO se mide por la rapidez con que se realizan los cambios de rol. Las pruebas de conmutación por error verifican el cumplimiento de los objetivos de RTO.
Alta disponibilidad: Una base de datos en espera puede asumir el control mediante conmutación por error o conmutación de rol. Data Guard ofrece servicios administrados de aplicación para transiciones rápidas. GoldenGate puede implementar configuraciones activo-activo en algunos casos. Se reducen los tiempos de inactividad programados y no programados. Se cumplen los acuerdos de nivel de servicio (SLA) y se mejora la fiabilidad del servicio.
Equilibrio de carga e informes: Active Data Guard le permite abrir una base de datos en espera para lecturas. Puede descargar las tareas de generación de informes para reducir la carga en la base de datos principal. Las vistas materializadas pueden ofrecer informes locales con actualizaciones periódicas. Así mejora el rendimiento para los usuarios finales y los equipos de análisis.
Continuidad empresarial y mantenimiento: Puede aplicar parches o actualizaciones en modo de espera mientras el sistema principal sigue funcionando. Tras las pruebas, cambia los roles. Así reduce al mínimo el tiempo de inactividad durante el mantenimiento. También puede migrar plataformas mediante la replicación a un nuevo entorno.
Distribución de datos: Replica los datos en oficinas remotas o zonas en la nube. Las vistas materializadas o GoldenGate pueden enviar subconjuntos o datos filtrados. Admite aplicaciones distribuidas con copias locales.
Pruebas y desarrollo: Mantienes una réplica para pruebas de calidad o desarrollo. La actualizas periódicamente desde el entorno de producción, lo que permite a los equipos probar cambios sin poner en riesgo el entorno principal.
Tipos de replicación de bases de datos en Oracle
Oracle ofrece varios métodos. Cada uno se adapta a casos de uso distintos y presenta compromisos en cuanto al RPO, el RTO, la complejidad y las licencias. A continuación se presenta un resumen comparativo:
| Method | RPO | RTO | Use Case | Complexity | Licensing | Status | Oracle Version |
|---|
| Data Guard | Data Guard | Fast failover/switchover | HA/DR for Oracle only | Moderate | Included in EE | Current | 11g onwards |
| GoldenGate | Near-zero to configurable | Varies; depends on apply | Logical replication, heterogeneous, migrations, active-active | High | Separate license | Current | 11g onwards |
| Materialized Views | Scheduled lag | Depends on refresh | Reporting, caches, minimal sync | Low | Included in EE | Current | 11g onwards |
| Advanced Replication | Moderate; conflict risk | Slow for conflict resolution | Multi-master legacy | High | Included in EE | Legacy/Superseded | 11g,12c |
| Streams | Near-zero to async | Fast | Deprecated logical replication | High | Included but deprecated | Deprecated | Deprecated in 12c, desupported 19c |
¿Cómo replicar una base de datos Oracle?
Las siguientes descripciones generales orientan sobre la configuración y las operaciones. Consulte siempre la documentación de Oracle correspondiente a su versión y entorno.
Requisitos previos y planificación
Antes de configurar cualquier replicación: verifique la conectividad de red, asegure un ancho de banda suficiente y enlaces seguros. Confirme que las ediciones y licencias de Oracle permitan los métodos elegidos. Prepare copias de seguridad mediante RMAN. Asigne usuarios dedicados con los privilegios adecuados. Planifique el almacenamiento en los destinos alternativos o de registro. Defina los objetivos de RPO y RTO. Realice pruebas primero en un entorno de ensayo. Documente los procedimientos operativos para la configuración, supervisión y conmutación por error.
1. Configuración de Data Guard
Data Guard ofrece una base de datos en espera administrada para alta disponibilidad y recuperación ante desastres (HA/DR). Puede utilizar el agente (Broker) o una configuración manual. Data Guard activo añade la capacidad de lectura únicamente.
Habilite el modo ARCHIVELOG y el registro forzoso (FORCE LOGGING). Cree los registros de rehacer en espera (standby redo logs): uno más que el número de grupos de registros de rehacer. Establezca DB_UNIQUE_NAME tanto en la base de datos principal como en la de espera. Configure las entradas LOG_ARCHIVE_DEST_n: la base de datos principal envía los registros de rehacer a las ubicaciones de la base de datos de espera. Establezca FAL_SERVER y FAL_CLIENT para la resolución de brechas. Asegúrese de que los parámetros de inicialización coincidan en ambos lados.
Utilice RMAN DUPLICATE TARGET DATABASE FOR STANDBY desde la base de datos principal o realice una copia de seguridad y restauración en el host standby. Ajuste los parámetros de inicialización en el archivo de inicialización del standby: DB_NAME debe coincidir con la base de datos principal, mientras que DB_UNIQUE_NAME debe ser distinto. Configure la copia de seguridad automática del archivo de control. Asegúrese de que las entradas de red en los archivos tnsnames.ora y listener.ora sean correctas.
El agente (DGMGRL) simplifica la administración. Usted crea una configuración de DG, agrega la base de datos principal y la de espera, y establece el modo de protección (MAXAVAIL, MAXPERFORMANCE o MAXPROTECTION). El agente se encarga de la validación, las transiciones de rol y la supervisión del estado. La configuración manual utiliza comandos SQL y RMAN: usted edita los parámetros de inicialización y activa la recuperación administrada con ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT. Se recomienda utilizar el agente en la mayoría de las configuraciones.
El modo SYNC (SYNC o FASTSYNC) espera la confirmación del sistema en espera, lo que permite una pérdida de datos casi nula. ASYNC envía los registros de rehacer sin esperar, tolera la latencia de la red pero conlleva el riesgo de pérdida de datos. Configure el modo de protección según los requisitos de RPO. Supervise el retraso en la transmisión mediante V$ARCHIVE_DEST_STATUS y V$DATAGUARD_STATS.
En modo de espera, el proceso MRP (Managed Recovery Process) aplica los registros de rehacer. Con Active Data Guard, se abre la base de datos en espera en modo de solo lectura: ALTER DATABASE OPEN READ ONLY. Las consultas se ejecutan en la base de datos en espera sin afectar al proceso de aplicación. Supervise el retraso en la aplicación mediante V$ARCHIVE_DEST_STATUS con APPLIED_TIME.
Conmutación de prueba: conmutación planificada en la que la base de datos principal pasa a ser la de respaldo. Utilice DGMGRL SWITCHOVER TO standby. Conmutación por fallo de prueba: conmutación no planificada, en la que la base de datos principal es inaccesible. Utilice DGMGRL FAILOVER TO standby. Tras el cambio de rol, vuelva a configurar la base de datos original como nueva base de respaldo. Documente los procedimientos y realice pruebas periódicamente.
Consulte las vistas V$ARCHIVE_DEST_STATUS y V$DATAGUARD_STATS para verificar el retraso en la transmisión y la aplicación. Utilice el comando DGMGRL SHOW CONFIGURATION para obtener el estado general. Configure alertas cuando el retraso supere el umbral establecido. Supervise el uso de los registros de red de standby (SRL) y el espacio disponible en la base de datos standby. Revise los errores de red en los registros de alertas. Automatice las notificaciones mediante scripts o herramientas de monitorización.
Las interrupciones de la red provocan brechas en los registros de rehacer (redo). Utilice FAL_SERVICE para recuperar los registros faltantes. Resuelva ejecutando ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL y luego reinicie la recuperación. La insuficiencia de los registros de rehacer en la base de datos en espera provoca una aplicación lenta. La retención de los registros de archivado debe tener en cuenta el consumo por parte de la base de datos en espera. Las incompatibilidades de versión impiden la aplicación; asegúrese de que los niveles de parches coincidan. Realice pruebas de conmutación por error (failover) para validar la configuración.
2. Configuración de GoldenGate
GoldenGate proporciona replicación lógica. Funciona en sistemas heterogéneos. Utiliza los procesos Extract, archivos de registro (trail files), Pump (opcional) y Replicat.
Habilite el registro suplementario: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA y ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS o ADD TRANDATA en las tablas. Esto garantiza que los datos de cambio necesarios se incluyan en el registro de rehacer (redo). Cree un usuario de GoldenGate con los privilegios requeridos.
Instale los binarios de GoldenGate en los servidores de origen y destino. Utilice versiones compatibles alineadas con la versión de Oracle Database. Configure el proceso Manager con la configuración de puertos.
Crear grupo de extracción: definir la base de datos y las tablas de origen. Especificar la ubicación del archivo de registro (trail file). Utilizar Extract integrado para Oracle para mejorar la eficiencia. Configurar tablas de puntos de control (checkpoint tables) en el esquema de destino para hacer un seguimiento del progreso. Opcionalmente, configurar Extract de bomba de datos (data pump Extract) para transferir los archivos de registro a los destinos.
Crear grupo de replicación: definir la base de datos y las tablas de destino. Configurar el almacén de credenciales o un alias para la autenticación segura. Usar archivos de parámetros para asignar los esquemas y tablas de origen a los de destino. Gestionar transformaciones o filtros en los archivos de parámetros.
GoldenGate puede replicar DDL con la configuración adecuada, pero requiere una planificación cuidadosa. Utilice DDL INCLUDEMAPPING o enfoques basados en scripts. Valide que el esquema de destino admita las nuevas estructuras.
Inicie los procesos Manager, Extract, Pump y Replicat mediante GGSCI. Utilice el comando INFO ALL para comprobar el estado y el retraso. Revise los archivos de informe en busca de errores. Supervise las métricas de retraso y el rendimiento. Utilice tablas de latido (heartbeat) para detectar interrupciones.
La replicación bidireccional requiere detección y resolución de conflictos. Utilice la compatibilidad con la globalización para conjuntos de caracteres. Para destinos heterogéneos, configure el mapeo según corresponda.
Proteja los archivos de registro con permisos a nivel de sistema operativo. Utilice enlaces de red cifrados o Secure Sockets para el transporte. Utilice el almacén de credenciales de GoldenGate para las contraseñas. Considere la integración con Oracle Key Vault.
Consulte las consultas INFO EXTRACT y INFO REPLICAT para verificar el retraso y el estado. Analice los archivos de informes en busca de errores. Establezca umbrales para el retraso y active alertas cuando se superen. Supervise las tablas de puntos de control para detectar retrasos. Utilice scripts u herramientas de supervisión para recopilar métricas.
La falta de registro suplementario provoca pérdida de datos. Detecte lag si los registros redo se sobrescriben; planifique la retención de los registros de archivo. Los cambios de DDL pueden fallar si no coinciden. Los problemas de red interrumpen la entrega de los archivos de trazas. Revise los registros del Administrador para detectar errores. Supervise el espacio en disco disponible para los archivos de trazas. Pruebe los escenarios de conmutación por error.
Para las actualizaciones de GoldenGate, coordine la detención y el reinicio de Extract y Replicat. Utilice una actualización escalonada para evitar tiempos de inactividad. Valide la compatibilidad con los nuevos parches de Oracle.
3. Configuración de vistas materializadas
Las vistas materializadas copian los datos a intervalos. Son adecuadas para informes o cachés.
En la fuente, cree registros de vistas materializadas en las tablas: CREATE MATERIALIZED VIEW LOG ON schema.table WITH ROWID. Esto permite la actualización rápida.
En el destino, CREATE MATERIALIZED VIEW mv_name REFRESH FAST ON DEMAND AS SELECT ... FROM schema.table@dblink;. Utilice ON COMMIT para actualizar de inmediato al confirmar cambios en la fuente, si esto es aceptable.
Utilice la actualización RÁPIDA cuando existan registros; de lo contrario, utilice la actualización COMPLETA. Programe la actualización mediante el Programador de Oracle: DBMS_SCHEDULER.CREATE_JOB. Supervise LAST_REFRESH_DATE en DBA_MVIEWS.
Consulte DBA_MVIEW_REFRESH_TIMES para ver el historial. Gestione los errores de actualización debidos a problemas de red o incoherencias en los tipos de datos. Asegúrese de tener los privilegios necesarios sobre los vínculos de origen. Administre los datos obsoletos seleccionando la frecuencia de actualización adecuada.
Informes casi en tiempo real en sitios distribuidos. Almacenamiento en caché de datos de referencia. Descarga de consultas desde el sistema principal.
4. Configuración avanzada de replicación (heredada)
La replicación avanzada utiliza grupos y trabajos de replicación. Admite la arquitectura de múltiples maestros, pero es una tecnología heredada. Para nuevos proyectos, debe utilizarse Oracle GoldenGate.
Defina el grupo de replicación mediante DBMS_REPCAT. Agregue sitios maestros. Defina los objetos replicados. Configure los métodos de resolución de conflictos. Programe trabajos de propagación. Supervise mediante DBA_REPCAT o vistas suministradas por Oracle.
No admite nuevas funciones de Oracle, como el entorno multitenant. Configuración compleja y gestión de conflictos. Soporte limitado por parte del proveedor. Sustituido por GoldenGate.
5. Streams (en desuso)
Oracle Streams proporcionaba replicación lógica. Quedó en desuso en la versión 12c y ya no es compatible a partir de la versión 19c. No lo utilice para nuevas implementaciones. Para necesidades similares, use Oracle GoldenGate.
Copia de seguridad segura de Oracle Database con Vinchin
Aunque se tenga la replicación implementada, las copias de seguridad siguen siendo esenciales. La replicación garantiza la disponibilidad, pero no protege contra todos los tipos de fallos. Por ello, sigue siendo necesario realizar copias de seguridad regulares y coherentes. Vinchin Backup & Recovery es una solución profesional de copia de seguridad para bases de datos a nivel empresarial que admite la mayoría de las bases de datos más utilizadas: Oracle, MySQL, SQL Server, MariaDB, PostgreSQL y PostgresPro.
Ofrece muchas funcionalidades; entre sus características principales se incluyen la copia de seguridad en la nube y el archivado en cinta, copias de seguridad completas e incrementales con soporte para registros archivados de Oracle, copias de seguridad programadas con compresión y desduplicación de datos, restauración en un nuevo servidor con recuperación hasta un punto específico en el tiempo y protección contra ransomware, entre otras. Específicamente para Oracle, incorpora compresión nativa de Oracle, soporte para seguimiento de cambios a nivel de bloque, omisión de archivos accesibles y omisión de archivos sin conexión para optimizar las tareas de copia de seguridad.
La consola web de Vinchin es sencilla e intuitiva. Realizar copias de seguridad de Oracle implica cuatro pasos claros:
1. Seleccione la base de datos que desea respaldar
2. Seleccione el almacenamiento de copia de seguridad,
3. Definir la estrategia de copia de seguridad
4. Enviar el trabajo.
La interfaz le guía con etiquetas y mensajes claros. Puede supervisar el progreso de las tareas, ver los registros y ajustar los horarios en la consola sin necesidad de comandos complejos.
Con una base global de clientes y altas calificaciones de sus productos, Vinchin ofrece una prueba gratuita de 60 días con todas las funciones — haga clic en el botón para descargar el instalador e implementarlo fácilmente.
Preguntas frecuentes sobre la replicación de Oracle Database
P1: ¿Cómo superviso el retraso en la aplicación de Data Guard?
Use SQL: SELECT DEST_ID, DEST_NAME, STATUS, RECEIVED_TIME, APPLIED_TIME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS NOT IN ('DEFERRED','INACTIVE'); revise V$DATAGUARD_STATS para obtener métricas del retraso.
P2: ¿Cómo resolver las brechas cuando vuelve a producirse un error en el transporte?
Ejecute ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; luego recupere los registros que faltan mediante FAL_SERVER; reinicie la recuperación: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT.
P3: ¿Cómo probar la conmutación por error de GoldenGate?
Detenga el proceso Extract en el origen; promueva el destino como nuevo origen; ajuste los parámetros de Extract para capturar desde el nuevo origen; reinicie los procesos; una vez solucionado, vuelva a configurar el origen original como destino.
P4: ¿Cómo afecta la replicación al rendimiento del sistema primario?
El modo SYNC añade latencia en la confirmación; el modo ASYNC añade muy poca. La captura de GoldenGate incrementa la generación de registros redo y el uso de la CPU. Supervise los informes AWR y las métricas del sistema; dimensione los recursos en consecuencia.
P5: ¿Cómo elegir entre Data Guard y GoldenGate?
Utilice Data Guard para la alta disponibilidad (HA) y la recuperación ante desastres (DR) principales dentro de Oracle. Utilice GoldenGate para la replicación lógica, destinos heterogéneos, filtrado, migraciones sin tiempo de inactividad y escenarios de múltiples maestros.
Conclusión
La replicación de Oracle mejora la disponibilidad, la resistencia y la escalabilidad. Data Guard y GoldenGate satisfacen la mayoría de las necesidades empresariales. Las vistas materializadas son adecuadas para informes, mientras que las opciones heredadas siguen utilizándose de forma limitada. Para operaciones eficaces se requieren objetivos claros de RPO/RTO, pruebas exhaustivas y supervisión proactiva. Asegure la replicación mediante cifrado y credenciales.
Siempre combine la replicación con copias de seguridad confiables. Vinchin ofrece una solución de copia de seguridad robusta para Oracle. Pruebe su versión de prueba gratuita para proteger su entorno.
