About Oracle Data Guard

You can use Oracle Data Guard on a DB system. Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.

For more information on Oracle Data Guard, see Introduction to Oracle Data Guard.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you’re using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.

If you’re new to policies, see Getting Started with Policies and Common Policies.

General Information

Oracle Data Guard configuration requires at least two databases: one in a primary role and one in a standby role. The primary and standby databases together constitute a Data Guard configuration. Most of the applications access the primary database. A standby database is a transactionally consistent copy of the primary database.

Data Guard Group provides the ability to create and manage multiple local and remote standby databases linked to a primary database, providing flexibility for both data protection and disaster recovery. In a Data Guard Group, a primary database can support up to a maximum of six standby databases.

Oracle Data Guard maintains the standby database by transmitting and applying redo data from the primary database. If the primary database becomes unavailable, then you can use Data Guard to switchover or failover the standby database to the primary role. This is true even if you have more than one standby database.

• Switchover: A switchover reverses the primary and standby database roles.
• Failover: A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable.
• Reinstate: Reinstates a database into the standby role in a Data Guard configuration.

In a typical Data Guard configuration, two standby databases are commonly used:

• Local Standby: A standby database in the same region as the production database is ideal for failover scenarios, offering zero data loss for local failures (such as database, cluster, or availability domain failures). Application failover impact is reduced in this case, as applications continue operating without the performance overhead of communicating with a remote region.
• Remote (Cross-Region) Standby: A remote standby database, located in a different region, is typically used for disaster recovery or to offload read-only query processing. A remote standby database setup ensures data protection against regional failures.

Some enterprise customers aim for symmetry after a site switch. For example, they may prefer to have both the primary and local standby in Region 1, and a remote standby with its own local standby in Region 2. In this configuration, there will be three standby databases. After a site switch, you will still have a primary database and a local standby readily available in the new primary region.

Additionally, you can enhance their configurations by adding another standby database for testing purposes, leveraging our snapshot (read/write) standby capabilities.

A Data Guard configuration requires atleast two DB systems, one containing the primary database and one containing the standby database. When you enable Data Guard for a database, a new DB system with the standby database is created and associated with the primary database.

Additional requirement details are as follows:

• The database versions and editions must be identical. For 26ai databases, the primary and standby databases must be on the same major release version, while the standby database can be on a higher minor version.
• Data Guard does not support Oracle Database Standard Edition. (Active Data Guard requires Enterprise Edition Extreme Performance.)
• Each database in a Data Guard configuration must have a unique name (DB_UNIQUE_NAME) value that is not in use by other databases in the DB systems that house the Data Guard configuration. However, the primary and standby database can use the same database name DB_NAME value.
• The database edition determines whether Active Data Guard (ADG) can be used. ADG is only available with Enterprise Edition Extreme Performance. If you are using the BYOL licensing model and if your license does not include ADG, then you must ensure that ADG is not enabled when configuring Data Guard for Enterprise Edition Extreme Performance. Alternately, you can use Enterprise Edition or Enterprise Edition High Performance, which do not enable ADG by default. See Use Oracle Data Guard with the Database CLI.
• If your primary and standby databases are in the same region, then both must use the same virtual cloud network (VCN).
• If your primary and standby databases are in different regions, then you must peer the virtual cloud networks (VCNs) for each database. See Remote VCN Peering using an RPC.
• The primary and standby databases could be in a different region, but they must be in the same realm.
• The SYS password and the TDE wallet password of the primary and standby databases must all be the same.
• A cross-region Data Guard is also supported if the database is using OCI Vault for TDE keys.

• Configure the security list ingress and egress rules for the subnets of the DB systems in a Data Guard configuration to enable TCP traffic to move between the applicable ports. Ensure that the rules you create are stateful (the default).

  For example, if the subnet of the primary DB system uses the source CIDR 10.0.0.0/24 and the subnet of the standby DB system uses the source CIDR 10.0.1.0/24, then create rules as shown in the subsequent example. Note that the egress rules in the example show how to enable TCP traffic only for port 1521, which is a minimum requirement for the Data Guard to work. If TCP traffic is already enabled on all of your outgoing ports (0.0.0.0/0), then you do not need to explicitly add these specific egress rules.

• The standby databases in OCI are physical standbys.
• Creating a standby database associated with another standby database (“cascading standby”) is not supported.
• You can create a Data Guard configuration when the database is encrypted using OCI Vault. However, OCI Vault currently supports key replication to only one remote region. As a result, cross-region Data Guard configurations for the databases using OCI Vault are limited to two regions: the primary region and one remote region. Multiple standby databases can be created within these regions, but configurations spanning three or more regions are not supported.

Known Issues

• In a cross-region Data Guard, after you perform a switchover, you cannot rotate the Database KMS key on the new primary database.
• In a cross-region Data Guard, after you perform a switchover, you cannot create a PDB on the new primary database.

Security List for Subnet on the Primary DB System

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

Security List for Subnet on the Standby DB System

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

For information about creating and editing rules, see Security Lists.

Availability Domain and Fault Domain Considerations for Oracle Data Guard

Oracle recommends that the DB system that contains the standby database be in a different availability domain from that of the DB system containing the primary database to improve availability and disaster recovery. If you enable Oracle Data Guard for a database and your standby database is in the same availability domain as the primary database (either by choice, or because you are working in a single availability domain region), then Oracle recommends that you place the standby database in a different fault domain from that of the primary database.

Note: If your primary and standby databases are two-node Oracle RAC databases and both are in the same availability domain, then only one of the two nodes of the standby database can be in a fault domain that does not include any other nodes from either the primary or standby database. This is because each availability domain has only three fault domains, and the primary and standby databases have a combined total of four nodes. For more information on availability domains and fault domains, see Regions and Availability Domains.