Cuando se utiliza una base de datos en espera de Autonomous Data Guard en la región actual, Autonomous Database aprovisiona una base de datos en espera local y supervisa la base de datos principal; si la base de datos principal deja de estar activa, la instancia en espera asume automáticamente el rol de la instancia principal.

Las bases de datos peer de Autonomous Data Guard locales conllevan el costo adicional de las CPU base y el almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento escalado automáticamente, que se factura en la propia base de datos principal. Las CPU de escala automática de la base de datos primaria no se facturan adicionalmente en la base de datos peer local de Autonomous Data Guard. Consulte Facturación de funciones de Oracle Autonomous Database Serverless para obtener más información.

Con una base de datos en espera local, Autonomous Data Guard proporciona una base de datos en espera idéntica que, según el estado de la base de datos principal, permite lo siguiente:

• Si la base de datos principal deja de estar activa, Autonomous Data Guard convierte la base de datos en espera en la base de datos principal con una interrupción mínima. Una vez finalizado el failover, Autonomous Data Guard crea una nueva base de datos en espera.

• Puede realizar una operación de switchover, en la que la base de datos principal se convierte en la base de datos en espera y la base de datos en espera se convierte en la base de datos principal.

Autonomous Database no proporciona acceso a una base de datos en espera en la región actual. Puede realizar todas las operaciones, como escalar verticalmente el recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU) y activar la escala automática de recursos informáticos en la base de datos principal y, a continuación, Autonomous Data Guard realizará las mismas acciones en la base de datos en espera local. Del mismo modo, en la base de datos principal solo puede realizar acciones como parar o reiniciar la base de datos.

La base de datos en espera local se crea en la misma región que la base de datos principal (región actual). Para mejorar la flexibilidad, la base de datos en espera se aprovisiona de la siguiente manera:

• En regiones con más de un dominio de disponibilidad, la base de datos en espera local se aprovisiona automáticamente en un dominio de disponibilidad diferente al de la base de datos principal.

• En regiones con un único dominio de disponibilidad, se provisiona automáticamente una base de datos en espera local en un dominio de errores diferente al de la base de datos principal (es decir, en una máquina física diferente).

Consulte Regiones y dominios de disponibilidad para obtener más información sobre los dominios de disponibilidad.

Todas las funciones de Autonomous Database de la base de datos principal están disponibles cuando la instancia en espera local se convierte en la principal, después de que el sistema falle o después de realizar una operación de switchover, incluidas las siguientes:

• Opciones de base de datos: las opciones Recuento de ECPU (Recuento de OCPU si la base de datos utiliza OCPU), Storage, Display Name, Database Name, Auto Scaling, Tags y Licensing tienen los mismos valores después de un failover en la base de datos en espera o después de realizar un switchover.

• Blocs de notas de OML: los blocs de notas y usuarios creados en la base de datos principal están disponibles en la base de datos en espera.

• Datos y metadatos de APEX: la información de APEX creada en la base de datos principal se copia en la base de datos en espera.

• ACL: la lista de control de acceso (ACL) de la base de datos principal se duplica para la base de datos en espera.

• Punto final privado: el punto final privado de la base de datos principal se aplica a la base de datos en espera.

• API o scripts: cualquier API o script que utilice para gestionar Autonomous Database siguen funcionando sin cambios después de una operación de failover o después de realizar un switchover.

• Conexiones de aplicación de cliente: las aplicaciones de cliente no necesitan cambiar sus cadenas de conexión para conectarse a la base de datos después de un failover en la base de datos en espera o después de realizar un switchover.

• Conexiones basadas en carteras: puede seguir utilizando las carteras existentes para conectarse a la base de datos después de un failover en la base de datos en espera o después de realizar un switchover.

Al agregar una base de datos en espera en una región diferente, si la instancia principal deja de estar activa, Autonomous Data Guard proporciona una base de datos en espera que está separada físicamente en una región remota. La base de datos en espera está disponible para asumir el rol de la instancia principal no disponible.

Una base de datos en espera entre regiones es una réplica de la base de datos principal y se puede utilizar para la recuperación en caso de fallo o cuando la base de datos principal no esté disponible. La activación de Autonomous Data Guard con una base de datos en espera entre regiones proporciona una solución de RTO baja para la recuperación ante desastres en caso de que una región completa no esté disponible o cuando la base de datos principal esté caída por cualquier motivo.

Las bases de datos en espera entre regiones de Autonomous Data Guard conllevan el costo adicional de las CPU base y el doble del almacenamiento de la base de datos primaria, incluido cualquier uso de almacenamiento escalado automáticamente, facturado en la base de datos peer remota. Las CPU de escala automática de la base de datos principal no se facturan adicionalmente en la base de datos peer remota. El número de CPU base se especifica mediante el número de ECPU (OCPU si la base de datos utiliza OCPU), como se muestra en el campo Recuento de ECPU (Recuento de OCPU) de la consola de Oracle Cloud Infrastructure.

Autonomous Database permite crear una o más bases de datos peer de recuperación ante desastres remotas, en función del modelo informático:

• Modelo de recursos informáticos de OCPU: puede agregar una base de datos en espera remota en una región emparejada. Las regiones emparejadas son regiones remotas en las que puede crear un peer entre regiones.

• Modelo de recursos informáticos de ECPU: puede agregar varios peers de recuperación ante desastres remotos, con hasta un peer en cada región emparejada remota. Por ejemplo, si la base de datos primaria está en la región IAD, puede agregar una base de datos en espera en PHX y una base de datos en espera en SJC, pero no puede agregar dos pares de recuperación ante desastres remotos en PHX.

Las regiones emparejadas son regiones remotas en las que puede crear una base de datos en espera entre regiones. Consulte Regiones emparejadas entre regiones de Autonomous Database para obtener más información sobre las regiones asociadas.

Puede realizar casi todas las operaciones, como escalar verticalmente el recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU) y activar la escala automática de recursos informáticos en la base de datos principal. A continuación, Autonomous Data Guard realiza las mismas acciones en la base de datos en espera entre regiones.

Después de agregar una base de datos en espera remota, Autonomous Database proporciona acceso a la base de datos en espera remota desde la consola de Oracle Cloud Infrastructure. Autonomous Database proporciona acceso a la base de datos en espera remota para que pueda realizar algunas operaciones de forma independiente en la base de datos en espera remota, como configurar redes y redes virtuales en la nube para puntos finales privados y agregar etiquetado para definir claves y valores que no se replican entre la base de datos primaria y la base de datos en espera remota.

No puede conectarse a una base de datos en espera entre regiones mientras funciona como base de datos en espera y no está disponible para operaciones de solo lectura. Puede conectarse a la base de datos en los siguientes casos:

• Cuando la base de datos asume el rol principal después de una operación de failover o switchover. Consulte Perform a Switchover y Perform a Manual Failover para obtener más información.

• Después de convertir una base de datos en espera a una base de datos de instantánea en espera. Consulte Conversión del peer de recuperación ante desastres entre regiones en una base de datos de instantánea en espera para obtener más información.

Las siguientes áreas presentan diferencias en el failover o el cambio de la base de datos primaria a una base de datos en espera remota, en comparación con el failover o el cambio a una base de datos en espera local:

• Nombre mostrado: el nombre mostrado tiene la extensión "_region". Donde región es el nombre de la región, como IAD o BOM.

  Si ha creado el par entre regiones antes de la introducción del soporte para varios pares entre regiones, el nombre mostrado del par entre regiones tiene una extensión "_Remote".

• Blocs de notas de OML: después de un switchover o failover entre regiones, los blocs de notas de OML de la base de datos principal que se ha realizado un switchover o un failover no están presentes en la base de datos principal (la base de datos principal actual después del cambio de rol). Se pueden crear nuevos blocs de notas de OML.

• Punto final privado: puede configurar y actualizar de forma independiente los puntos finales privados en una base de datos en espera antes del failover o de realizar un switchover. Esto permite tener un punto final privado configurado de forma diferente, después del failover o después de realizar un switchover. Autonomous Database no mantiene la configuración de red sincronizada de la base de datos principal a una base de datos en espera remota.

  El intercambio de tráfico de VCN y el reenvío de dominio son necesarios para que las carteras funcionen entre regiones, con instancias de Autonomous Database con un punto final privado con una base de datos en espera de Autonomous Data Guard, donde la base de datos principal y la base de datos en espera están en distintas redes virtuales en la nube. Consulte Intercambio de tráfico de VCN remotas a través de una RPC y DNS en su red virtual en la nube para obtener información sobre el intercambio de tráfico de VCN y el reenvío de dominios.

• Lista de control de acceso de red: de forma predeterminada, una base de datos primaria de recuperación ante desastres y bases de datos peer remotas utilizan las mismas listas de control de acceso de red (ACL). Opcionalmente, puede editar de forma independiente las ACL de red en una base de datos peer remota. Esto permite utilizar diferentes ACL en una base de datos peer remota.

  Consulte Gestión de ACL de red peer remota para obtener más información.

• Etiquetas: las etiquetas se gestionan de forma independiente en una base de datos principal de recuperación ante desastres y en una base de datos peer remota. Esto significa que:

  • Al agregar, eliminar o actualizar una etiqueta en un peer remoto, el cambio se aplica solo en la base de datos peer remota.

  • Al agregar, actualizar o eliminar una etiqueta en la principal, la etiqueta no se agrega, actualiza ni elimina en bases de datos peer remotas.

• API o scripts: todas las API o scripts que utilice para gestionar Autonomous Database se deben actualizar para llamar a las API de la base de datos principal, la base de datos principal actual, después de un failover o después de realizar un switchover.

  Para las conexiones mTLS, debe descargar una cartera de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Cadenas y carteras de conexión de recuperación ante desastres entre regiones para obtener más información.

• Aplicaciones de cliente: las aplicaciones de cliente deben conectarse mediante las cadenas de conexión y la cartera que descarga de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Cadenas y carteras de conexión de recuperación ante desastres entre regiones para obtener más información.

• Conexiones basadas en cartera: debe descargar una cartera y conectarse mediante las cadenas de conexión de la base de datos primaria, la base de datos primaria actual, para conectarse a la base de datos después de un failover o después de realizar un switchover. Consulte Cadenas y carteras de conexión de recuperación ante desastres entre regiones para obtener más información.

• Autonomous Database Herramientas: las herramientas tienen diferentes URL en la base de datos principal, la base de datos principal actual, después de un failover o después de realizar un switchover (las URL de las herramientas no cambian para un switchover o un failover en una base de datos en espera local):

  • Database Actions

  • Oracle APEX

  • Oracle REST Data Services (ORDS)

  • Graph Studio

  • Oracle Machine Learning Notebooks

  • Transformaciones de datos

  • API de MongoDB

• Uso de Object Storage de Oracle Cloud Infrastructure: después de realizar un failover o un switchover de la base de datos primaria a una base de datos en espera, en la base de datos primaria (la base de datos primaria actual) las credenciales y las URL que proporcionan acceso a Object Storage siguen funcionando igual que antes del failover o el switchover, proporcionando acceso a lo siguiente:

  • tablas externas

  • Tablas particionadas externas

  • Tablas particionadas híbridas externas

  Nota
  
  : esto se aplica cuando está disponible Object Storage. En los raros escenarios en los que no esté disponible Object Storage, Oracle recomienda hacer copias de seguridad o una replicación de Object Storage en una región diferente. Si no está disponible Object Storage (es decir, el recurso de Object Storage que ha utilizado con la instancia principal antes de un switchover o failover), puede actualizar las credenciales de usuario y los parámetros que definen las URL de Object Storage para que los parámetros especifiquen valores para acceder a la instancia de Object Storage de una región disponible. Consulte Uso de la replicación para obtener más información.

• Rol de base de datos de Autonomous Data Guard
  Después de agregar una base de datos en espera entre regiones, cada base de datos tiene un rol designado: principal, en espera o de instantánea en espera.
• Failover y switchover entre regiones de Autonomous Data Guard
  Puede tener un peer de recuperación ante desastres local y, opcionalmente, puede agregar uno o más peers entre regiones (se permiten varios peers entre regiones con el modelo de recursos informáticos de ECPU). En los casos local y entre regiones, cualquiera de los pares puede ser una copia de Recuperación ante desastres basada en copia de seguridad o una base de datos en espera de Autonomous Data Guard.
• Copia de seguridad y restauración entre regiones de la base de datos de Autonomous Data Guard
  Después de agregar una base de datos en espera entre regiones de Autonomous Data Guard, la copia de seguridad y la restauración a partir de la copia de seguridad se gestionan de la siguiente manera:
• Cadenas y carteras de conexión de recuperación ante desastres entre regiones
  Al agregar una base de datos en espera entre regiones (remota) de Autonomous Data Guard o al utilizar un peer de recuperación ante desastres basada en copias de seguridad entre regiones, la cartera y la cadena de conexión de la base de datos principal solo contienen el nombre de host de la base de datos principal.
• Autonomous Data Guard con claves gestionadas por el cliente
  Al agregar una base de datos en espera entre regiones de Autonomous Data Guard, hay consideraciones especiales cuando la base de datos principal utiliza claves gestionadas por el cliente o si desea cambiar al uso de claves gestionadas por el cliente en la base de datos principal.
• Replicación de copias de seguridad en una base de datos en espera de Autonomous Data Guard entre regiones
  Al agregar una base de datos en espera de Autonomous Data Guard entre regiones, puede activar la replicación de copia de seguridad entre regiones para que las copias de seguridad automáticas de la base de datos principal también estén disponibles en una región remota.
• Límite de BYOL entre regiones de Autonomous Data Guard
  El límite de ECPU de BYOL definido en una base de datos principal de Autonomous Data Guard no se aplica a una base de datos en espera de Autonomous Data Guard entre regiones o entre arrendamientos.

El RTO es el periodo máximo de tiempo necesario para restaurar la conectividad de la base de datos a una base de datos en espera después de iniciar un failover manual o automático. El RPO es la duración máxima de la pérdida potencial de datos en la base de datos principal.

Autonomous Database proporciona las siguientes operaciones con Autonomous Data Guard:

• Activar: si utiliza Recuperación ante desastres basada en copia de seguridad, puede actualizar el tipo de recuperación ante desastres a Autonomous Data Guard local (región actual) o puede agregar una base de datos en espera entre regiones de Autonomous Data Guard.

  Consulte Activación de Autonomous Data Guard y Adición de una base de datos en espera entre regiones para obtener más información.

• Desactivar: si tiene una base de datos en espera local o una base de datos en espera entre regiones, puede cambiar el tipo de recuperación ante desastres a Recuperación ante desastres basada en copia de seguridad para la base de datos en espera local o puede terminar una base de datos en espera entre regiones. En cualquier caso, la desactivación de Autonomous Data Guard termina la base de datos en espera.

  Consulte Actualización de la base de datos en espera para utilizar un peer de copia de seguridad o Desactivación de una base de datos en espera entre regiones para obtener más información.

• Switchover: cuando Autonomous Data Guard está activado, el switchover cambia los roles de la base de datos principal y de la base de datos en espera. De este modo, la base de datos en espera se convierte en la base de datos principal y la base de datos principal se convierte en la base de datos en espera. Si tiene una base de datos en espera local (región actual) y una base de datos en espera entre regiones (remota), puede elegir realizar el cambio a la base de datos en espera local o a la base de datos en espera remota.

  Consulte Realizar un switchover para obtener más información.

• Error manual: si la base de datos principal no está disponible, puede realizar un failover manual para cambiar los roles a fin de convertir una base de datos en espera en la base de datos principal:

  • Si hay disponible una base de datos en espera local, puede realizar un failover manualmente a la base de datos en espera local (no tendrá la opción de realizar un failover a una base de datos en espera remota si hay disponible una base de datos en espera local).
  • Si una base de datos en espera local no está disponible, puede realizar un failover manual a una base de datos en espera remota.

  Consulte Realización de un failover manual para obtener más información.

• Convertir a base de datos de instantánea en espera: la conversión de un par de recuperación ante desastres a una instantánea en espera abre la base de datos en modo de lectura-escritura y el par de recuperación ante desastres entre regiones detiene temporalmente el refrescamiento de los datos de la base de datos origen.

  Consulte Conversión del par entre regiones a la base de datos en espera de instantánea para obtener más información.

• Terminar: si desea terminar una instancia principal, seleccione Más acciones y Terminar. Al terminar la instancia principal, también termina una base de datos en espera local.

  Si tiene una base de datos en espera local (región actual) y una base de datos en espera entre regiones, debe terminar la base de datos en espera entre regiones antes de terminar la base de datos primaria.

  Consulte Terminación de una base de datos en espera entre regiones para obtener más información.

Autonomous Database proporciona información sobre el estado de recuperación ante desastres en la página Detalles de Autonomous Database.

En el área Recuperación ante desastres:

El campo Rol muestra el rol de la base de datos actual de la siguiente manera:

• Cuando tiene un peer de copia de seguridad local o una base de datos en espera de Autonomous Data Guard local, la consola de Oracle Cloud Infrastructure muestra el valor del campo rol principal. Autonomous Database no proporciona acceso a una base de datos en espera local (o a un peer de copia de seguridad local).

• Cuando se utiliza un peer de copia de seguridad entre regiones o una base de datos en espera de Autonomous Data Guard entre regiones, la consola de Oracle Cloud Infrastructure muestra el campo Rol con el valor Principal si está viendo la base de datos principal, y muestra En espera si está viendo los detalles de una base de datos en espera.

• Switchover: proporciona un enlace para que pueda realizar una operación de switchover.

• Failover: cuando la base de datos principal no está disponible, si tiene una base de datos en espera local y no se ha realizado correctamente un failover automático, el enlace de failover permite iniciar un failover manual.

  Cuando la base de datos principal no está disponible, si tiene una base de datos en espera entre regiones y no es posible realizar un failover a una base de datos en espera local, el enlace de failover permite iniciar un failover manual a la base de datos en espera remota.

Para ver la información de Autonomous Database de peer, en Recursos, haga clic en Recuperación ante desastres. En este área se muestra la información de la base de datos autónoma de peer. La columna Estado muestra el estado de una base de datos en espera de la siguiente manera:

• Aprovisionamiento

  • Este estado se muestra cuando se activa Autonomous Data Guard e indica que se está aprovisionando una base de datos en espera (hasta que el estado de la base de datos en espera cambie a En espera).

  • Este estado se muestra después de un failover a una base de datos en espera local mientras se vuelve a crear una base de datos en espera local.

  • Este estado se muestra si se ha realizado una restauración a partir de una operación de copia de seguridad en la base de datos principal y se está volviendo a crear la base de datos en espera local, y la columna Estado muestra Aprovisionando.

• En espera: indica que hay una base de datos en espera disponible y lista para una operación de conmutación o de failover.

  Nota
  
  Cuando se para una base de datos en espera, en el estado en espera se muestra En espera. Una base de datos en espera nunca muestra el estado Parado.

• Cambio de roles en curso:: indica que se ha iniciado una operación de failover o switchover.

Puede utilizar eventos de Oracle Cloud Infrastructure para responder cuando Autonomous Database cambie su estado debido a un evento relacionado con Autonomous Data Guard, como una operación de failover o switchover.

Los eventos de Autonomous Database son:

• Iniciar failover automático
• Finalizar failover automático
• Iniciar desactivación de Autonomous Data Guard
• Iniciar activación de Autonomous Data Guard
• Iniciar failover
• Iniciar switchover
• Finalizar desactivación de Autonomous Data Guard
• Finalizar activación de Autonomous Data Guard
• Finalizar failover con un resultado de failover correcto o incorrecto
• Finalizar switchover con un resultado de switchover correcto o incorrecto

En función de los eventos, puede realizar acciones o enviar notificaciones. Consulte Eventos y notificaciones con una base de datos en espera para obtener más información sobre el uso de eventos y la producción de notificaciones.