Protección de bases de datos críticas frente a fallos y desastres mediante Autonomous Data Guard

Acerca de Autonomous Data Guard

Autonomous Data Guard crea y mantiene dos copias completamente independientes de la base de datos: una base de datos primaria a la que se conectan y que utilizan las aplicaciones, y una base de datos en espera que es una copia sincronizada de la base de datos principal. Entonces, si la base de datos principal deja de estar disponible por cualquier motivo, Autonomous Data Guard puede convertir la base de datos en espera en la base de datos principal y, como tal, comenzará a prestar servicio a las aplicaciones.

Las bases de datos principal y en espera a menudo se denominan bases de datos peer entre sí. Puede tener hasta dos bases de datos en espera por base de datos de contenedores autónoma.

Note:

Las aplicaciones se deben configurar de modo que utilicen la continuidad de aplicaciones transparente (TAC) para obtener todas las ventajas de las funciones de disponibilidad de base de datos que proporciona Autonomous Data Guard.

En el siguiente diagrama se muestra cómo se mantiene sincronizada cada base de datos en espera con la base de datos principal.

A continuación se incluye la descripción de autonomous-data-guard.eps

Descripción de la ilustración autonomous-data-guard.eps

Los cambios realizados en la base de datos principal se registran en el redo log de la base de datos principal. Autonomous Data Guard transmite estos registros de redo como un flujo a través de la red al redo log de la base de datos en espera. A continuación, la base de datos en espera aplica estos registros a la base de datos en espera. De esta forma, la base de datos en espera se mantiene sincronizada con la base de datos principal.

La sincronización es casi instantánea, pero, como implica el proceso que se acaba de describir, hay dos operaciones que consumen tiempo: transportar los registros de redo a la base de datos en espera y aplicar los registros de redo a la base de datos en espera. La primera de ellas se denomina demora de transporte, y la otra se denomina demora de aplicación. Puede ver los valores de demora actuales de una instancia de Autonomous Database en la página Detalles de la base de datos de Autonomous Data Guard, en Recursos. en Recursos, en el menú lateral. Puede ver los valores de demora actuales en todas las Autonomous Database de una base de datos de contenedores en la página Detalles de la base de datos de contenedores de forma similar.

Note:

Con varias bases de datos en espera, el transporte de redo en cascada no está soportado.

Configuración de Autonomous Data Guard

En Autonomous Database on Dedicated Exadata Infrastructure, puede configurar y gestionar Autonomous Data Guard en el nivel de Autonomous Container Database (ACD). Puede activar Autonomous Data Guard para bases de datos de contenedor autónomas ya aprovisionadas y agregar hasta dos bases de datos de contenedor autónomas en espera desde su página Detalles mediante la consola de Oracle Cloud Infrastructure. Consulte Activación de Autonomous Data Guard en una base de datos de contenedores autónoma y Adición de una segunda base de datos de contenedores autónoma en espera para obtener instrucciones.

Tenga en cuenta lo siguiente antes de configurar Autonomous Data Guard:

Las instancias de Autonomous Database desplegadas en Exadata Cloud@Customer deben tener abierto el puerto 1522 para permitir el tráfico TCP entre la base de datos principal y la base de datos en espera en una configuración de Autonomous Data Guard.
Autonomous Data Guard no se puede activar en una ACD con una ejecución de mantenimiento activa programada en los próximos tres días. Puede ejecutar primero el mantenimiento activo y, a continuación, activar Autonomous Data Guard o cambiar el programa de ejecución de mantenimiento para que no comience hasta que se agregue la segunda base de datos en espera.
La adición de una segunda base de datos en espera requiere un reinicio automático sin acumulación para la primera base de datos en espera. La base de datos primaria no se ve afectada por este reinicio sin acumulación.

Configurar Autonomous Data Guard con claves gestionadas por el cliente

En Autonomous Database en infraestructura de Exadata dedicada, puede configurar y gestionar Autonomous Data Guard con claves gestionadas por el cliente a nivel de base de datos de contenedores autónoma (ACD). Puede activar Autonomous Data Guard para las ACD ya aprovisionadas y agregar hasta dos ACD en espera desde su página Detalles mediante la consola de Oracle Cloud Infrastructure. Consulte Activación de Autonomous Data Guard en una base de datos de contenedores autónoma y Adición de una segunda base de datos de contenedores autónoma en espera para obtener instrucciones.

Tenga en cuenta lo siguiente antes de configurar Autonomous Data Guard con claves gestionadas por el cliente:

Si utiliza Oracle Cloud Infrastructure Key Management System (OCI KMS) y desea activar Autonomous Data Guard entre regiones, primero debe replicar el almacén de OCI en la región en la que desea agregar la base de datos en espera. Consulte Replicación de almacenes y claves para obtener más información.

Note:
Los almacenes virtuales creados antes de que se introdujera la función de replicación de almacén entre regiones no se pueden replicar entre regiones. Cree un nuevo almacén y nuevas claves si tiene un almacén que necesita replicar en otra región y la replicación no está soportada para ese almacén. Sin embargo, todos los almacenes privados admiten la replicación entre regiones. Consulte Replicación de almacén virtual entre regiones para obtener más información.
Si utiliza Oracle Key Vault (OKV) y desea activar Autonomous Data Guard entre regiones, asegúrese de que ha agregado direcciones IP de conexión para el cluster de OKV en el almacén de claves.

Modelos de Autonomous Data Guard

A partir del marzo de 2025, las bases de datos de contenedores autónomas (ACD) pueden activar Autonomous Data Guard desde su página Detalles y crear hasta dos ACD en espera. Con esta versión, el modelo anterior Asociaciones de Autonomous Data Guard y las API asociadas quedarán en desuso y se sustituirán por el modelo y las API nuevosgrupos de Autonomous Data Guard. Todas las bases de datos de contenedor autónomas nuevas aprovisionadas después de marzo de 2025 desde la consola de Oracle Cloud Infrastructure (OCI) utilizarán automáticamente el nuevo modelo de grupos de Autonomous Data Guard.

Para realizar la transición de las bases de datos de contenedor autónomas existentes, los clientes pueden migrar al nuevo modelo haciendo clic en Actualizar a grupos de Autonomous Data Guard desde la página Detalles de la base de datos de contenedor autónoma en la consola de OCI o mediante la API MigrateAutonomousContainerDatabaseDataguardAssociation.

Al actualizar:

Cambiará a la nueva experiencia de usuario en la que se realizan operaciones de Autonomous Data Guard en el recurso Base de datos de contenedores autónoma en lugar del recurso Asociación de Data Guard de bases de datos de contenedores autónomas.
El recurso Asociaciones de Autonomous Data Guard se convierte en un recurso Grupos de Autonomous Data Guard con varios soportes en espera. No hay ningún impacto en la configuración existente de Autonomous Databases o Data Guard.
Debe activar Autonomous Data Guard desde la página Detalles de la ACD después de aprovisionarla para utilizar la función Autonomous Data Guard.
Debe iniciar las operaciones de switchover y failover desde la ACD en espera a la que desea cambiar roles con la ACD principal o failover, respectivamente.
Cambiará a las nuevas API de grupos de Autonomous Data Guard que se muestran como API de sustitución en API para gestionar la configuración de Autonomous Data Guard. La API existente de Autonomous Data Guard Associations está en desuso y no estará disponible a partir de marzo de 2026.
Debe suscribirse a los nuevos eventos de grupos de Autonomous Data Guard que se muestran en Tipos de eventos de Autonomous Data Guard. Los eventos existentes de Asociaciones de Autonomous Data Guard solo funcionarán con la antigua API de Asociaciones de Autonomous Data Guard y quedarán en desuso junto con estas API.

Transiciones y operaciones de roles

Después de crear una base de datos de contenedores autónoma (ACD), puede cambiar el rol de las bases de datos peer mediante una operación de switchover o de failover. Si el failover automático está activado, Autonomous Data Guard realiza automáticamente una operación de failover siempre que la base de datos principal no esté disponible, por cualquier motivo.

Un switchover es una reversión de rol entre la base de datos principal y la base de datos en espera. Un switchover garantiza que no se produzcan pérdidas de datos. Durante una operación de switchover, la base de datos principal realiza la transición al rol en espera y la base de datos en espera realiza la transición al rol principal. Para realizar una operación de switchover, consulte Cambio de roles en una configuración de Autonomous Data Guard.

Un failover se produce cuando la base de datos principal no está disponible. El failover genera una transición de la base de datos en espera al rol de principal. Si el failover automático no está activado, puede realizar un failover manual como se describe en Failover a la base de datos en espera en una configuración de Autonomous Data Guard.

La disponibilidad y el estado de la base de datos después de una operación de failover se caracterizan por dos objetivos de recuperación:

Objetivo de tiempo de recuperación (RTO). El objetivo de tiempo de recuperación (RTO) es la cantidad máxima de tiempo necesaria para que la base de datos esté disponible para las aplicaciones después de un failover y está relacionado en cierta medida con la demora de aplicación en el momento del fallo. Para Autonomous Data Guard, el RTO son los segundos hasta un máximo de dos minutos.
Objetivo de punto de recuperación (RPO). El RPO es la duración máxima de la posible pérdida de datos de la base de datos principal con fallos y está relacionado en cierta medida con la demora de transporte en el momento del fallo. Para Autonomous Data Guard, el RPO es de casi cero.

Después de un failover, la base de datos primaria con fallos se convierte en una base de datos en espera desactivada y permanece no disponible para ninguna conexión a la base de datos. Puede volver a activarla y convertirla en una base de datos en espera en buen estado realizando una operación reinstate. Una vez que se haya restablecido una base de datos primaria fallida como base de datos en espera, puede realizar una operación de switchover para devolverla a su rol principal original. Para realizar una operación de nueva instanciación, consulte Nueva instanciación de la base de datos en espera desactivada en una configuración de Autonomous Data Guard.

Failover automático o failover de inicio rápido

Con el failover automático, cuando la ACD principal deja de estar disponible debido a un fallo de región, un fallo de un dominio de disponibilidad, un fallo de la infraestructura de Exadata o del cluster de VM de Exadata autónomo (AVMC), o al fallo de la propia ACD, se produce un failover automático a la ACD en espera. También se denomina failover de inicio rápido.

No puede activar el failover automático al configurar Autonomous Data Guard en una ACD. El failover automático solo se puede activar o desactivar al actualizar la configuración de Autonomous Data Guard desde la página Detalles de ACD.

Note:

No se puede activar el failover automático para instancias de Autonomous Database desplegadas en Exadata Cloud@Customer con configuración de Autonomous Data Guard entre regiones.

No puede agregar una segunda ACD en espera con el failover automático activado para la primera ACD en espera. Por lo tanto, desactive el failover automático mediante Actualizar configuración de Autonomous Data Guard antes de crear la segunda ACD en espera y vuelva a activarla más tarde, si es necesario.

Los modos de protección de máximo rendimiento y máxima disponibilidad soportan el failover automático:

En el modo Máxima disponibilidad, el failover automático garantiza que no se produzca pérdida de datos.
En el modo máximo rendimiento, el failover automático garantiza que la base de datos en espera no vaya por detrás de la base de datos principal más allá del valor especificado para límite de demora de failover de inicio rápido. Por defecto, el Límite de demora de failover de inicio rápido está definido en 30 segundos y solo se aplica al modo Máximo rendimiento. En este caso, el failover automático solo es posible cuando la demora de aplicación (posible pérdida de datos) de la base de datos en espera no supera el límite de demora configurado. Puede modificar el límite de demora de failover de Fast Start a cualquier valor entre 5 y 3600.

Consulte Actualización de la configuración de Autonomous Data Guard para obtener más información.

Además de los fallos de hardware, las interrupciones del dominio de disponibilidad y las interrupciones regionales, existen otras condiciones de estado de base de datos que pueden disparar un failover de inicio rápido, como se muestra a continuación:

Estado de la base de datos	Descripción
Archivo de control corrupto	Se ha dañado el archivo de control de forma permanente debido a un fallo del disco.
Diccionario corrupto	Daños en el diccionario de una base de datos esencial. Actualmente, este estado solo se puede detectar cuando la base de datos está abierta.
Errores de escritura de archivo de datos	Se detectan errores de escritura en cualquier archivo de datos, incluidos los archivos temporales, los archivos de datos del sistema y los archivos de deshacer.

Como resultado del failover automático, el rol de la base de datos principal con fallos pasa a ser Base de datos en espera desactivada y, después de un breve período, la base de datos en espera asume el rol de la base de datos principal. Una vez que ha finalizado el failover automático, aparece un mensaje en la página de detalles de la base de datos en espera desactivada que le indica que se ha producido un failover.

Después de que el servicio haya resuelto las incidencias anteriores de la base de datos de contenedores autónoma principal, puede realizar un switchover manual para devolver ambas bases de datos a sus roles iniciales. Después de aprovisionar la base de datos en espera, puede realizar varias tareas de gestión relacionadas con la base de datos en espera, como:

Realizar un switchover manual de una base de datos principal a una base de datos en espera.
Realizar un failover manual de una base de datos principal a una base de datos en espera.
Volver a instanciar una base de datos principal a un rol en espera después de un failover.
Terminar una base de datos en espera.

En una configuración de Autonomous Data Guard con varias bases de datos en espera y failover automático:

Los failovers manuales requieren que vuelva a instanciar manualmente la base de datos primaria original, que se convierte en la nueva base de datos en espera.
Cuando se produce un failover automático, Autonomous Database on Dedicated Exadata Infrastructure intenta volver a instanciar la base de datos principal antigua como base de datos en espera. Sin embargo, si ese intento falla, se debe volver a instanciar manualmente.

Base de Datos de Instantánea en Espera

Una base de datos de instantánea en espera es una base de datos en espera completamente actualizable creada mediante la conversión de una base de datos de contenedores autónoma (ACD) en espera a una ACD de instantánea en espera. Consulte Convert Physical Standby to Snapshot Standby para obtener instrucciones paso a paso.

Una base de datos de instantánea en espera recibe y archiva, pero no aplica, los datos de redo de la base de datos principal. Sin embargo, aumenta el objetivo de tiempo de recuperación (RTO) porque no se aplican los cambios en tiempo real de la base de datos primaria.

La función de instantánea en espera soporta varios casos de uso, pero estos son los casos de uso principales.

Conecte las instancias de aplicación principal y en espera a las bases de datos principal y en espera en modo de lectura-escritura para realizar las configuraciones iniciales.
Aplique primero un parche a la base de datos de instantánea en espera y pruebe con la instancia de la aplicación en espera para confirmar la estabilidad del parche. Para ello es necesario convertir primero la base de datos física en espera en una base de datos de instantánea en espera, para que el parche se pueda aplicar en la base de datos de instantánea en espera.

Note:

No puede convertir una base de datos de contenedores autónoma física en espera en una instantánea en espera con el failover automático activado.

Al realizar la conversión a una instantánea en espera, puede activar nuevos servicios de base de datos que estén activos solo en modo de instantánea o utilizar el mismo juego de servicios que se utiliza con la base de datos primaria. Sin embargo, la activación de los servicios de la base de datos principal en la base de datos de instantánea en espera puede hacer que las solicitudes de conexión de instantánea en espera se reenvíen a la base de datos principal o viceversa si utiliza cadenas de conexión de base de datos incorrectas. Por lo tanto, debe tener cuidado de utilizar la cadena de conexión adecuada al conectarse a la base de datos principal y de instantánea en espera.

Note:

Al crear nuevos servicios con instantánea en espera, se actualizan las carteras de todas las instancias de Autonomous Database de la ACD de instantánea en espera. Para acceder a la base de datos, vuelva a cargar las carteras desde las instancias de Autonomous Database en espera y utilice cadenas de conexión de instantánea en espera.

Puede volver a convertir la ACD de instantánea en espera en una ACD física en espera desde Oracle Cloud Infrastructure (OCI) manualmente. Consulte Conversión de Bases de Datos de Instantánea en Espera a Bases de Datos Físicas en Espera para obtener instrucciones detalladas. Si una base de datos de instantánea en espera no se convierte manualmente en una base de datos física en espera, se volverá a convertir automáticamente en una base de datos física en espera después de 7 días desde su creación. En cualquier caso, al volver a convertir la instantánea en espera en una física en espera, se desecharán todas las actualizaciones locales de las bases de datos de instantánea en espera y se aplicarán los datos de redo recibidos de las bases de datos primarias.

Cuando una ACD en espera está en modo de instantánea en espera, no puede realizar las siguientes operaciones en la ACD principal:

Crear o terminar bases de datos autónomas
Amplíe o reduzca verticalmente las bases de datos autónomas
Restaurar bases de datos autónomas

Si la situación lo exige, puede realizar un failover manual a una instantánea en espera desde la base de datos primaria. En ese caso, el failover convierte la base de datos de instantánea en espera en una base de datos física en espera desechando todas las actualizaciones locales realizadas en la instantánea en espera y aplicando los datos de la base de datos principal. Consulte Fail Over to the Standby in an Autonomous Data Guard Configuration para obtener instrucciones paso a paso.

No se permite un switchover entre la base de datos primaria y la base de datos de instantánea en espera. Debe convertir manualmente la base de datos de instantánea en espera en una base de datos física en espera antes de realizar un switchover.

Acceso a bases de datos en espera desde aplicaciones cliente

En una configuración de Autonomous Data Guard, las aplicaciones cliente normalmente se conectan a la base de datos principal y realizan operaciones en ella.

Conexión a la Base de Datos Física en Espera

Además de esta conectividad normal, Autonomous Data Guard le ofrece la opción de conectar las aplicaciones cliente que realizan operaciones de solo lectura en la base de datos en espera. Para aprovechar esta opción, las aplicaciones cliente se conectan a la base de datos mediante nombres de servicio de base de datos que incluyen "_RO" ("solo lectura"), como se describe en Nombres de servicio de base de datos predefinidos para instancias de Autonomous Database.

Conexión a la Base de Datos de Instantánea en Espera

Autonomous Data Guard también permite conectar aplicaciones cliente que realizan operaciones de lectura y escritura a la base de datos de instantánea en espera. Estas operaciones son locales para la base de datos de instantánea en espera y no modifican su base de datos primaria. Para conectarse a una base de datos de instantánea en espera, las aplicaciones cliente pueden utilizar nombres de servicio de base de datos que incluyan "_SS" (para "instantánea en espera"), como se describe en Nombres de servicio de base de datos predefinidos para bases de datos autónomas.

Note:

Cuando la base de datos en espera está en modo de instantánea en espera, todos los servicios de base de datos que incluyen servicios "_RO" en su nombre están inactivos y no se pueden utilizar para conexiones.

Supervisión de tiempos de demora

Mientras se ejecutan las bases de datos que utilizan Autonomous Data Guard, puede supervisar los tiempos de demora de transporte y de aplicación desde la página Detalles de la base de datos (o de la base de datos de contenedores) seleccionando Asociaciones de Autonomous Data Guard en Recursos en el menú lateral. También puede utilizar la consola de OCI o las API de observabilidad para supervisar la demora de transporte y configurar alarmas y notificaciones. Consulte Observación de bases de datos con métricas de Autonomous Database para obtener más información.

Debe esperar que aparezcan fluctuaciones menores a lo largo del tiempo a medida que la carga de trabajo de la base de datos cambia y fluye. Sin embargo, si observa una tendencia ascendente continua en el tiempo de demora, puede realizar estas acciones para resolver la situación:

Tendencia ascendente en la demora de aplicación. Una tendencia ascendente continua en la demora de aplicación indica que la base de datos en espera no tiene capacidad suficiente para asumir los registros de redo procedentes de la base de datos principal. Para resolver esta situación, amplíe las OCPU de la base de datos, como se describe en Adición de recursos de almacenamiento o CPU a una instancia de Autonomous Database dedicada.
Tendencia ascendente en la demora de transporte. Una tendencia ascendente continua en la demora de transporte indica una incidencia de rendimiento de red. El personal de operaciones de Oracle Cloud supervisa de manera constante el rendimiento de la red, por lo que la situación debería resolverse sin que realice ninguna acción. Sin embargo, si lo desea, puede informar de la situación al personal de operaciones mediante la emisión de una solicitud de servicio, como se describe en Creación de una solicitud de servicio en My Oracle Support.

Opciones de configuración de Autonomous Data Guard

Al crear una base de datos de contenedores autónoma con Autonomous Data Guard activado, especifique en qué recursos de infraestructura de Exadata y de cluster de VM de Exadata autónomo desea crear la base de datos en espera y especifique qué modo de protección de datos desea utilizar.

Tiene las siguientes opciones al especificar qué recursos de infraestructura de Exadata y de cluster de VM de Exadata autónomo se utilizarán para la base de datos en espera:

En una región diferente de la infraestructura de Exadata y el cluster de VM de Exadata autónomo de la base de datos principal:
Esta elección proporciona el nivel más alto de protección contra desastres, incluida una pérdida catastrófica de la conectividad de red externa o de la alimentación a toda una región.

Para aprovechar al máximo esta protección entre regiones, el nivel de aplicación también se debe configurar de modo que soporte la protección entre regiones. Por lo tanto, Oracle recomienda que elija esta opción si el nivel de aplicación ya está configurado de esta forma o si desea volver a configurarlo de modo que soporte la protección entre regiones.

Si decide ubicar la base de datos en espera en una región diferente, Oracle recomienda utilizar el modo de protección Maximum Performance.
En un dominio de disponibilidad (AD) diferente (AD) de la infraestructura de Exadata y el cluster de VM de Exadata autónomo de la base de datos principal:
Esta elección proporciona un alto nivel de protección contra desastres, incluida una pérdida catastrófica de conectividad de red externa o de energía a un dominio de disponibilidad dentro de una región.

Esta opción proporciona un buen equilibrio entre la protección de datos y la simplicidad de la configuración en el nivel de aplicación.

Si decide ubicar la base de datos en espera en un dominio de disponibilidad diferente, Oracle recomienda utilizar el modo de protección máxima disponibilidad.
En el mismo dominio de disponibilidad que la infraestructura de Exadata y el cluster de VM de Exadata autónomo de la base de datos principal:
Esta opción proporciona un nivel mínimo de protección contra desastres y Oracle recomienda que no la seleccione.

Si los recursos de infraestructura de Exadata y de cluster de VM de Exadata autónomo de la base de datos principal están en una región que solo tiene un dominio de disponibilidad, Oracle recomienda utilizar la opción de "en una región diferente".

Si decide ubicar la base de datos en espera en el mismo dominio de disponibilidad, Oracle recomienda utilizar el modo de protección Máxima disponibilidad.
En un arrendamiento diferente al de la infraestructura de Exadata y el cluster de VM de Exadata autónomo de la base de datos principal:
Se aplica a: Oracle Public Cloud solo

Esta opción permite agregar una base de datos en espera de un arrendamiento diferente, lo que permite realizar un failover o switchover de la base de datos en esa base de datos en espera entre arrendamientos. También puede crear una instantánea en espera en el arrendamiento remoto. Tener una base de datos en espera entre arrendamientos puede ser útil con la migración de bases de datos entre arrendamientos.

Bases de datos en espera entre arrendamientos:
- Se puede activar con el modelo de recursos informáticos de ECPU u OCPU. La base de datos en espera debe utilizar el mismo modelo de cálculo que la base de datos principal.
- No admite el failover automático. En su lugar, solo puede utilizar un failover manual.
- No se puede agregar mediante la consola de Oracle Cloud Infrastructure. Solo puede agregar una base de datos en espera entre arrendamientos mediante la CLI o la API de REST.

Acerca de los modos de protección

Autonomous Data Guard proporciona estos modos de protección de datos:

Máxima Disponibilidad. Este modo de protección proporciona el máximo nivel de protección de datos posible sin poner en riesgo la disponibilidad de la base de datos principal.

La base de datos principal no confirma las transacciones hasta que recibe la confirmación de que los datos se han recibido en la base de datos en espera (no se han escrito en el disco). Si la base de datos principal no recibe esta confirmación en un plazo de 30 segundos, funcionará como si estuviera en modo de máximo rendimiento para mantener la disponibilidad de la base de datos principal hasta que vuelva a recibir las confirmaciones de forma oportuna.

Este modo de protección garantiza que no se pierda ningún dato, excepto en el caso de determinados fallos dobles, como un fallo de una base de datos principal tras un fallo de la base de datos en espera.
Máximo Rendimiento. Este es el modo de protección por defecto. Proporciona el nivel de protección de datos más alto posible sin afectar al rendimiento de la base de datos principal.

La base de datos principal confirma las transacciones tan pronto como todos los datos de redo generados por esas transacciones se hayan escrito en su redo log en línea. También envía datos de redo a la base de datos en espera, pero esto se realiza de forma asíncrona con respecto a la confirmación de transacción, por lo que el rendimiento de la base de datos principal no se ve afectado por los retrasos en la escritura de datos de redo en la base de datos en espera.

Este modo de protección ofrece una protección de datos ligeramente inferior al modo de máxima disponibilidad y tiene un impacto mínimo en el rendimiento de la base de datos principal.

Puede cambiar el modo de protección en una configuración de Autonomous Data Guard desde la consola de Oracle Cloud Infrastructure (OCI). Consulte Actualización de la configuración de Autonomous Data Guard para obtener instrucciones paso a paso.

Para obtener más información sobre los modos de protección en Oracle Data Guard (que subyacen a la función Autonomous Data Guard), consulte la sección sobre los modos de protección de Oracle Data Guard en Oracle Data Guard Concepts and Administration.

Mejores prácticas al configurar Autonomous Data Guard

Aunque Autonomous Database permite crear hasta dos bases de datos de contenedor autónomas en espera con Autonomous Data Guard, puede optar por utilizar una o varias bases de datos de contenedor autónomas en espera, según sus necesidades. Sin embargo, para utilizar la opción de recuperación ante desastres más resistente que ofrece una instancia de Autonomous Database, puede agregar una base de datos de contenedor autónoma en espera local y una base de datos de contenedor autónoma en espera remota o entre regiones con disponibilidad máxima como modo de protección de datos.

Veamos las ventajas de este diseño:

En espera local:
- El failover automático a una base de datos en espera local en la misma región proporciona un aislamiento de desastres local significativo y una simplicidad de failover de la aplicación.
- El valor de negocio de una base de datos local en espera se observa en un failover sin pérdida de datos y un tiempo de inactividad de la aplicación reducido a segundos.
- Las aplicaciones realizan una operación de failover automática y transparente en la base de datos en espera local, manteniendo la misma latencia entre los servidores de aplicaciones y la base de datos. Esto es especialmente importante para las aplicaciones OLTP y de paquetes porque una mayor latencia puede afectar significativamente al rendimiento global y al tiempo de respuesta general de la aplicación.
En espera remota:
- Si un desastre regional hace que los sistemas en espera principal y local sean inaccesibles, la aplicación y la base de datos pueden realizar un failover a la base de datos en espera remota.
- Aunque el tiempo de inactividad de la base de datos sigue siendo muy bajo cuando se produce un desastre regional, el tiempo de inactividad de la aplicación puede ser mayor debido a la orquestación adicional necesaria para las operaciones de failover de DNS, aplicación y base de datos en la región secundaria.
Máxima Disponibilidad:
- Si el failover automático o el failover de inicio rápido (FSFO) están activados, cuando la base de datos de contenedor autónoma principal deja de estar disponible, Autonomous Data Guard realiza un failover a la base de datos en espera local sin pérdida de datos y sin cambios en la latencia de la base de datos en la aplicación.
- Si está activado el failover automático o el failover de inicio rápido (FSFO), siempre que no se pueda acceder a toda la región principal, el sistema realiza un failover a la base de datos en espera remota con una posible pérdida de datos.

Cómo afecta Autonomous Data Guard a las operaciones de gestión estándar

En algunos casos, las operaciones de gestión estándar que realice en las bases de datos de contenedores autónomas funcionan de manera diferente en las bases de datos de contenedores principal y en espera en una configuración de Autonomous Data Guard en comparación con las bases de datos de contenedores estándar. En la siguiente lista se describen estas diferencias.

Cambiar el programa de mantenimiento
La programación del mantenimiento de una base de datos de contenedores principal y su base de datos en espera están enlazadas: el mantenimiento en la base de datos en espera se realiza varios días antes que el mantenimiento en la base de datos principal. El valor por defecto es 7 días; puede elegir entre 1 y 7 días al crear la base de datos de contenedores principal, o posteriormente mediante la edición de los detalles de mantenimiento.
Cambiar el tipo de mantenimiento
El tipo de mantenimiento de una base de datos de contenedores principal y su base de datos en espera debe ser el mismo. Puede elegir el tipo de mantenimiento para la base de datos de contenedores principal y la base de datos en espera al crear la base de datos de contenedores principal o posteriormente, mediante la edición de los detalles de mantenimiento.
Desactivar copias de seguridad automáticas
No puede desactivar las copias de seguridad automáticas al aprovisionar una base de datos de contenedores autónoma (ACD) con Autonomous Data Guard.
Gestión del mantenimiento programado
Puede gestionar el mantenimiento programado de una base de datos de contenedores principal y su base de datos en espera por separado. Sin embargo, debido a que el mantenimiento de las dos está enlazado, debe realizar el mantenimiento programado en la base de datos en espera antes que en la principal si decide cambiar la hora de mantenimiento programado.
Traslado a un compartimento diferente
Puede mover las bases de datos de contenedores principal y en espera a diferentes compartimentos por separado y de forma independiente, al igual que si fueran bases de datos de contenedores estándar. Sin embargo, como ocurre con las bases de datos de contenedores estándar, debe tener el máximo cuidado al mover una base de datos de contenedor para asegurarse de que esta sigue siendo accesible para los grupos adecuados de usuarios en la nube.
Reiniciar
Puede reiniciar las bases de datos de contenedores principal y en espera por separado y de forma independiente, al igual que si fueran bases de datos de contenedores estándar.
Rotación de la clave de cifrado
Puede rotar las claves de cifrado desde la base de datos ACD o primaria principal.
Finalizar
Puede terminar las bases de datos de contenedores principal y en espera por separado. Sin embargo, las consecuencias de terminar una base de datos de contenedores principal y terminar una base de datos de contenedores en espera son diferentes:
- Al terminar una base de datos de contenedor principal se termina tanto la bases de datos de contenedores principal como la de espera. No puede terminar una base de datos de contenedores principal que contenga bases de datos autónomas.
- Al terminar una base de datos de contenedores en espera, se termina la base de datos de contenedores en espera y se elimina de la configuración de Autonomous Data Guard. Si solo queda una base de datos principal, se elimina la configuración de Autonomous Data Guard, lo que convierte la principal en una base de datos de contenedores independiente.

Guías paso a paso

Para obtener orientación paso a paso sobre la gestión de la configuración de Autonomous Data Guard en una base de datos de contenedores autónoma, consulte:

También puede utilizar una API para ver y gestionar la configuración de Autonomous Data Guard. Para obtener más información, consulte la sección sobre la API para gestionar la configuración de Autonomous Data Guard.