How to configure Autonomous Data Guard
Now let’s talk a little bit about Oracle Autonomous Data Guard.
When you enable Autonomous Data Guard, the system creates a standby database that continuously gets updated with the changes from the primary database.
With Autonomous Data Guard enabled Autonomous Database provides one identical standby database that allows the following, depending on the state of the primary database:
• If your primary database goes down, Autonomous Data Guard converts the standby database to the primary database with minimal interruption. After failover completes, Autonomous Data Guard creates a new standby database for you.
• You can perform a switchover operation, where the primary database becomes the standby database, and the standby database becomes the primary database.
Autonomous Database does not provide access to the standby database. You perform all operations, such as scaling up the OCPU Count and enabling Auto Scaling on the primary database and Autonomous Data Guard then performs the same actions on the standby database. Likewise, you only perform actions such as stopping or restarting the database on the primary database.
Autonomous Data Guard Features
Autonomous Data Guard monitors the primary database and if the Autonomous Database instance goes down, then the standby instance assumes the role of the primary instance.
The standby database is created in the same region as the primary database. For better resilience, the standby database is provisioned as follows:
In regions with more than one availability domain, the standby database is provisioned automatically in a different availability domain than the primary database.
In regions with a single availability domain, the standby database is provisioned automatically on a different physical machine than the primary database.
All Autonomous Database features from the primary database are available when the standby instance becomes the primary after the system fails over or after you perform a switchover operation, including the following:
OML Notebooks: Notebooks and users created in the primary database are available in the standby.
APEX Data and Metadata: APEX information created in the primary database is copied to the standby.
ACLs: The Access Control List (ACL) of the primary database is duplicated for the standby.
Private Endpoint: The private endpoint from the primary database applies to the standby.
APIs or Scripts: Any APIs or scripts you use to manage the Autonomous Database continue to work without any changes after a failover operation or after you perform a switchover.
Client Application Connections: Client applications do not need to change their connection strings to connect to the database after a failover to the standby database or after you perform a switchover.
Wallet Based Connections: You can continue using your existing wallets to connect to the database after a failover to the standby database or after you perform a switchover.
Database Options: The OCPU Count, Storage, Display Name, Database Name, Auto Scaling, Tags, and Licensing options have the same values after a failover to the standby database or after you perform a switchover.
When Autonomous Data Guard is enabled the RTO and RPO numbers are as follows:
Automatic Failover: the RTO is two (2) minutes and RPO is zero (0).
Manual Failover: the RTO is two (2) minutes and RPO is up to five (5) minutes.
Notes for enabling Autonomous Data Guard:
To enable Autonomous Data Guard the database version must be Oracle Database 19c or higher.
Autonomous Database generates the Enable Autonomous Data Guard work request. To view the request, under Resources click Work Requests.
While you enable Autonomous Data Guard, when the Peer State field shows Provisioning, the following actions are disabled for the database:
Move Resource
Stop
Restart
Restore
Enable Autonomous Data Guard
1. If you are not logged in to Oracle Cloud Console, log in and navigate to your Autonomous Database.
2. Under Autonomous Data Guard section, click Enable to enable the Data Guard feature.
3. In the Enable Autonomous Data Guard dialog, click Enable Autonomous Data Guard.
4. The Autonomous Database Lifecycle State changes to Updatingand on the Details page, under Autonomous Data Guard the Peer State field shows Provisioning. Depending on the size of your primary database this may take several minutes.
When the standby database is being provisioned, the primary database status becomes available and all database activities can continue as enabling Autonomous Data Guard is non-blocking.
When provisioning completes, the Peer State field shows Available.
Test Switchover to a Standby Database
After Autonomous Data Guard is enabled, if you perform a switchover operation the primary database becomes the standby database, and the standby database becomes the primary database, with no data loss. A switchover is typically done to test your application’s failover procedures when Autonomous Data Guard is enabled.
The Oracle Cloud Infrastructure console shows a switchover link in the Peer State field when both the primary database and the standby database are available. That is, the primary database Lifecycle State field shows Available or Stopped and the standby database is available (the Peer State field shows Available).
To perform a switchover, do the following:
1 .On the Details page, under Autonomous Data Guard, in the Peer State field, click Switchover
The database Lifecycle State changes to Updating and the Peer State field shows Role Change in Progress.
When the switchover operation completes, Autonomous Data Guard does the following:
The Primary database goes into the Available state and can be connected to for queries and updates.
The Peer State field will change to Available when the standby is ready. (The standby may go into a Provisioning state first, if necessary, without blocking operations on the Primary.)
You can see the time of the last switchover when you hover over the tooltip icon in the Peer State field.
I hope this helps you!!!
Andre Luiz Dutra Ontalba
Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful
