Acerca de Oracle Data Guard

Puede utilizar Oracle Data Guard en un Sistema de Base de Datos. Oracle Data Guard garantiza alta disponibilidad, protección de datos y recuperación ante desastres para los datos empresariales.

Para obtener más información sobre Oracle Data Guard, consulte Introducción a Oracle Data Guard.

Política de IAM necesaria

Para poder utilizar Oracle Cloud Infrastructure, un administrador debe otorgarle acceso de seguridad en una política. Este acceso es necesario tanto si utiliza la Consola como la API de REST con un SDK, una CLI u otra herramienta. Si recibe un mensaje que le indica que no tiene permiso o no está autorizado, verifique con su administrador el tipo de acceso que tiene y en qué compartimento debe trabajar.

Si no está familiarizado con las políticas, consulte Introducción a las políticas y Políticas comunes.

Información General

La configuración de Oracle Data Guard requiere al menos dos bases, una en un rol principal y otra en un rol de espera. Las bases de datos primaria y en espera juntas constituyen una configuración de Data Guard. La mayoría de las aplicaciones acceden a la base datos primaria. Una base de datos en espera es una copia transaccionalmente consistente de la base de datos primaria.

El grupo de Data Guard proporciona la capacidad de crear y gestionar varias bases de datos en espera locales y remotas enlazadas a una base de datos primaria, proporcionando flexibilidad tanto para la protección de datos como para la recuperación ante desastres. En un grupo de Data Guard, una base de datos primaria puede soportar hasta un máximo de seis bases de datos en espera.

Oracle Data Guard mantiene la base de datos en espera mediante la transmisión y la aplicación de datos de redo desde la base de datos principal. En caso de que la base datos principal deje de estar disponible, puede utilizar Data Guard para cambiar o realizar una conmutación por error de la base en espera al rol principal. Esto es cierto incluso si tiene más de una base de datos en espera.

• Switchover: Un switchover invierte los roles de las bases de datos principal y en espera.
• Failover: un failover pasa la base datos en espera al rol principal después de que falla o se vuelve inaccesible.
• Vuelta a instanciar: restablece una base de datos al rol en espera de una configuración de Data Guard.

En una configuración típica de Data Guard, se suelen utilizar dos bases de datos en espera:

• Bases de Datos en Espera Locales: una base de datos en espera en la misma región que la base de datos de producción es ideal para escenarios de failover, ofreciendo cero pérdida de datos para fallos locales (como fallos de base de datos, cluster o dominio de disponibilidad). El impacto de failover de la aplicación se reduce en este caso, ya que las aplicaciones siguen funcionando sin la sobrecarga de rendimiento que supone comunicarse con una región remota.
• Base de datos en espera remota (entre regiones): una base de datos en espera remota, ubicada en una región diferente, se suele utilizar para la recuperación ante desastres o para descargar el procesamiento de consultas de solo lectura. Una configuración de base de datos en espera remota garantiza la protección de datos frente a fallos regionales.

Algunos clientes empresariales buscan simetría después de un cambio de sitio. Por ejemplo, puede que prefieran tener tanto la base de datos en espera principal como la local en la región 1, y una base de datos en espera remota con su propia base de datos en espera local en la región 2. En esta configuración, habrá tres bases de datos en espera. Después de un cambio de ubicación, seguirá teniendo una base de datos primaria y una base de datos en espera local disponible en la nueva región primaria.

Además, puede mejorar sus configuraciones agregando otra base de datos en espera para fines de prueba, aprovechando nuestras capacidades de instantánea (lectura/escritura) en espera.

Una configuración de Data Guard requiere dos sistemas de base datos, uno que contenga la base del datos principal y otro que contenga la base del datos en espera. Cuando activa Data Guard para una base de datos, se crea un nuevo sistema de base de datos con la base de datos en espera y se asocia a la base de datos principal.

Los detalles adicionales de los requisitos son los siguientes:

• Las versiones y las ediciones de base de datos deben ser idénticas. Para las bases de datos 26ai, la base de datos principal y la base de datos en espera deben estar en la misma versión principal, mientras que la base de datos en espera puede estar en una versión secundaria superior.
• Data Guard no soporta Oracle Database Standard Edition. (Active Data Guard requiere Enterprise Edition Extreme Performance).
• Cada base de Datos de una configuración de Data Guard debe tener un valor del nombre único (DB_UNIQUE_NAME) que no esté en uso en otras bases de Datos de los sistemas de base de Datos que alojan la configuración de Data Guard. Sin embargo, las bases de datos principal y en espera pueden utilizar el mismo valor de nombre de base de datos DB_NAME.
• La edición de la base de datos determina si se puede utilizar Active Data Guard (ADG). ADG solo está disponible con Enterprise Edition Extreme Performance. Si utiliza el modelo de licencia BYOL y su licencia no incluye ADG, debe asegurarse de que ADG no está activado al configurar Data Guard para Enterprise Edition Extreme Performance. También puede utilizar Enterprise Edition o Enterprise Edition High Performance, que no activan ADG por defecto. Consulte Utilización de Oracle Data Guard con la CLI de la base de datos.
• Si las bases de datos principal y en espera están en la misma región, ambas deben utilizar la misma red virtual en la nube (VCN).
• Si las bases de datos principal y en espera están en diferentes regiones, debe emparejar las redes virtuales en la nube (VCN) de cada base de datos. Consulte Intercambio de tráfico de VCN remotas a través de una RPC.
• Las bases de datos primaria y en espera pueden estar en una región diferente, pero deben estar en el mismo dominio.
• Para que las contraseñas SYS y de cartera TDE de las bases de Datos principal y en espera funcionen, todas deben ser iguales.
• También está soportado un Data Guard entre regiones si la base de datos utiliza OCI Vault para claves de TDE.

• Configure las reglas para la entrada y salida de las listas de seguridad para las subredes de los sistemas de BD en una configuración de Data Guard para permitir que el tráfico TCP se mueva entre los puertos aplicables. Asegúrese de que las reglas que crea tengan estado (valor por defecto).

  Por ejemplo, si la subred del sistema de base de datos principal utiliza el origen CIDR 10.0.0.0/24 y la subred del sistema de base de datos en espera utiliza el origen CIDR 10.0.1.0/24, cree reglas como se muestra en el siguiente ejemplo. Tenga en cuenta que las reglas de entrada del ejemplo muestran cómo activar un tráfico TCP solo para un puerto 1521, que es un requisito mínimo para la función de Data Guard. Si el tráfico TCP ya está activado en todos los puertos salientes (0.0.0.0/0), no es necesario que agregue explícitamente estas reglas de salida específicas.

• La base de datos en espera de OCI es una base de datos física en espera.
• La creación de una base de datos en espera asociada a otra base de datos en espera ("base de datos en espera en cascada") no está soportada.
• Puede crear una configuración de Data Guard cuando la base de datos se cifra mediante OCI Vault. Sin embargo, OCI Vault soporta actualmente la replicación de claves en una sola región remota. Como resultado, las configuraciones de Data Guard entre regiones para las bases de datos que utilizan OCI Vault están limitadas a dos regiones: la región principal y una región remota. Se pueden crear varias bases de datos en espera en estas regiones, pero no están soportadas las configuraciones que abarcan tres o más regiones.

Incidencias conocidas

• En Data Guard entre regiones, después de realizar un switchover, no puede rotar la clave de KMS de la base de datos en la nueva base de datos primaria.
• En Data Guard entre regiones, después de realizar una operación de switchover, no puede crear una PDB en la nueva base de datos primaria.

Lista de seguridad para subred en el sistema a base de datos principal

Ingress Rules:
	Stateless: No
	Source: 10.0.1.0/24
	IP Protocol: TCPSource Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.1.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Lista de seguridad para subred en el sistema en espera de base de datos

Ingress Rules:
	Stateless: No
	Source: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Para obtener información sobre la creación y la edición de reglas, consulte Listas de seguridad.

Consideraciones acerca del dominio de disponibilidad y el dominio de errores para Oracle Data Guard

Oracle recomienda que el sistema de BD que contiene la BD en espera esté en un dominio del sistema de disponibilidad diferente que el del sistema de BD que contiene la BD principal para mejorar su disponibilidad y recuperación ante desastres. Si activa Oracle Data Guard para una base de datos y la base de datos en espera está en el mismo dominio de disponibilidad que la base de datos principal (ya sea por elección o porque está trabajando en una sola región de dominio de disponibilidad), Oracle recomienda colocar la base de datos en espera en un dominio de errores diferente al de la de la base de datos principal.

Nota: Si las Bases de Datos Principal y En Espera son Bases de Datos Oracle RAC de dos Nodos y ambas están en el mismo Dominio de Disponibilidad, solo uno de los dos Nodos de la Base de Datos en Espera puede estar en un Dominio de Errores que no incluya ningún otro nodo de la Base de Datos Principal o en Espera. Esto es debido a que cada dominio de disponibilidad solo tiene tres dominios de errores, y las bases de datos principal y en espera tienen un total combinado de cuatro nodos. Para obtener más información sobre los dominios de disponibilidad y los dominios de errores, consulte Regiones y dominios de disponibilidad.