Oracle AI Database 23.26.2 le permite desplegar una base de datos conectable (PDB) de standby y sus redo logs con un único comando de Data Guard Broker, eliminando la rutina de copiar archivos manualmente que durante mucho tiempo ha ralentizado las configuraciones de recuperación ante desastres.

Por qué esto es importante

Crear una PDB de standby física ha requerido una cadena de acciones manuales: copiar cada datafile al contenedor de standby, construir los standby redo logs (SRLs) con comandos ALTER explícitos y verificar toda la configuración. Cada paso conlleva el riesgo de un error tipográfico, un archivo omitido o un grupo de logs desajustado, lo que puede retrasar las pruebas de recuperación o, en el peor de los casos, romper el failover. Automatizar el proceso reduce esos riesgos y libera a los DBAs para que se concentren en tareas de mayor nivel.

Cómo se construían las PDB de standby anteriormente

En la arquitectura multitenant, una CDB (container database) primaria aloja una o más PDBs. Para proteger una PDB, los administradores tenían que:

  • Identificar y copiar cada datafile desde el host primario al de standby.
  • Crear manualmente SRLs que reflejen la estructura de redo-logs de la primaria.
  • Ejecutar restauraciones de RMAN o comandos de duplicación para sincronizar la standby.
  • Realizar una serie de pasos de verificación para asegurar que la standby pudiera aceptar un switchover.

El flujo de trabajo podía durar varias horas, especialmente para PDBs grandes, y cualquier error podía dejar la standby inutilizable.

Qué hace la actualización 23.26.2

La última versión de Oracle AI Database integra los pasos necesarios en el Data Guard Broker. Al ejecutar una única sentencia ADD PLUGGABLE DATABASE, el broker:

  1. Registra la nueva PDB de standby con la primaria.
  2. Copia los datafiles necesarios internamente; no se requiere restauración de RMAN ni copia manual de archivos.
  3. Genera los standby redo logs apropiados, añadiéndolos automáticamente a la CDB de standby.
  4. Deja la PDB en modo READ ONLY, lista para un switchover de standby física.

El comando utilizado en la prueba fue:

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

Una prueba en el mundo real

El autor creó una PDB de standby llamada AMOL en una CDB secundaria (cdb2) que reflejaba una PDB primaria en cdb1. El broker completó la operación instantáneamente. No se ejecutó ninguna restauración de RMAN, no aparecieron copias manuales de archivos en los logs del SO y los grupos de standby redo logs aparecieron en el catálogo sin necesidad de sentencias ALTER DATABASE.

Al abrir la PDB, esta cambió a modo READ ONLY, confirmando su estado de standby física. Una comprobación rápida de los datafiles demostró que habían sido aprovisionados en el lado de la standby. El redo apply ya estaba en ejecución y el broker informó que la configuración estaba lista para un switchover.

Implicaciones para los DBAs

La automatización reduce la posibilidad de error humano y reduce drásticamente el tiempo desde la planificación hasta la standby de producción. Los equipos ahora pueden aprovisionar PDBs de standby en minutos en lugar de horas, lo cual es especialmente valioso para entornos que despliegan nuevos servicios con frecuencia.

La contrapartida es una mayor dependencia de la lógica interna del Data Guard Broker. Algunos DBAs prefieren crear sus propios scripts para cada paso para mantener un control granular o para integrarse con herramientas de monitoreo personalizadas. En configuraciones complejas (múltiples redes, almacenamiento heterogéneo o estructuras de redo no estándar), los administradores aún pueden necesitar verificar que los valores predeterminados del broker se alineen con sus políticas.

Qué esperar a continuación

Oracle no ha anunciado más extensiones para esta automatización, pero este movimiento sugiere que las futuras versiones podrían trasladar más partes del flujo de trabajo de DR multitenant al broker. Esté atento a:

  • Soporte para tipos de standby adicionales (por ejemplo, PDBs de standby lógica).
  • Logging ampliado que muestre las decisiones del broker para fines de auditoría.
  • Comprobaciones de compatibilidad con herramientas de backup de terceros que anteriormente dependían de pasos manuales de RMAN.

Si su organización utiliza Oracle AI Database en una configuración de alta disponibilidad, probar el nuevo comando en una CDB que no sea de producción es la forma más rápida de evaluar el impacto.

Conclusión: Oracle AI Database 23.26.2 convierte una configuración de PDB de standby de múltiples pasos y propensa a errores en una operación de una sola línea, ofreciendo una recuperación ante desastres más rápida y confiable para entornos multitenant.