Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.
This is only applicable to Bare Metal and Virtual Machine DB systems.
The Oracle Cloud Infrastructure Data Guard implementation requires two databases: one in a primary role and one in a standby role. The two databases make an Oracle Data Guard association. Most of your applications access the primary database, while the standby database is a transactionally consistent copy of the primary database.
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 Oracle Data Guard to switch or fail over the standby database to the primary role.
Tip:The standby databases in Oracle Cloud Infrastructure are physical standbys.
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.
This topic explains how to use the Console to manage Oracle Data Guard associations in your DB system.
Prerequisites and General Information
An Oracle Data Guard implementation requires two DB systems, one containing the primary database and one containing the standby database. When you enable Oracle Data Guard for a virtual machine DB system database, a new DB system with the standby database is created and associated with the primary database. For a bare metal DB system, the DB system with the database that you want to use as the standby must already exist before you enable Oracle Data Guard.
Tip:An Oracle Data Guard configuration on the Oracle Cloud Infrastructure is limited to one standby database for each primary database.
Requirement details are as follows:
- Both DB systems must be in the same compartment.
- The DB systems must be the same shape type (for example, if the shape of the primary database is a virtual machine, then the shape of the standby database can be any other virtual machine shape).
- The database versions and editions must be identical. Oracle Data Guard does not support Oracle Database Standard Edition. (Active Data Guard requires Enterprise Edition - Extreme Performance.)
- Each database in a Data Guard association must have a unique name
DB_UNIQUE_NAME) value that is not in use by other databases in the DB systems the house the Data Guard association. However, the primary and standby database can use the same database name
- 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 Active Data Guard, then you must ensure that Active Data Guard 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.
- Configure the security list ingress and egress rules for the subnets of both DB
systems in the Oracle Data Guard association to enable TCP traffic to move between
the applicable ports. Ensure that the rules you create are stateful (the
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.
The egress rules in the example show how to enable TCP traffic only for port 1521, which is a minimum requirement for Oracle 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.
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.
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.
Use the API
For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.
Use these API operations to manage Data Guard associations:
- DeleteDbHome - To terminate a bare metal DB system Data Guard association, delete the standby database.
- TerminateDbSystem - To terminate a virtual machine DB system Data Guard association, terminate the standby DB system.
For the complete list of APIs for the Database service, see Database Service API.