Using Autonomous Data Guard with Autonomous Database on Exadata Cloud@Customer
Learn how to enable a Data Guard association between databases, change the role of a database in a Data Guard association using either a switchover or a failover operation, and reinstate a failed database.
- Enabling Autonomous Data Guard on an Autonomous Container Database
When you enable Data Guard, a separate Data Guard association is created for the primary and the standby database. - Enabling Autonomous Data Guard on an Autonomous Database
Autonomous Databases inherit Data Guard settings from the parent container database. - Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database
Follow these steps to change the maintenance schedule of a Data Guard enabled Autonomous Container Database.
Parent topic: Autonomous Database on Exadata Cloud@Customer
Enabling Autonomous Data Guard on an Autonomous Container Database
When you enable Data Guard, a separate Data Guard association is created for the primary and the standby database.
Replication of data happens only over the client network.
- Create an Autonomous Data Guard Enabled Autonomous Container Database
Follow these steps to create an Autonomous Data Guard Enabled Autonomous Container Database on an Oracle Exadata Cloud@Customer system. - View Details of a Data Guard Enabled Primary or Standby Autonomous Container Database
Follow these steps to view detailed information about a primary or standby Autonomous Container Database on an Oracle Exadata Database Service on Cloud@Customer system. - Edit Autonomous Container Database Backup Settings
If automatic backups were disabled while provisioning an Autonomous Container Database (ACD), you can enable them later from the Oracle Cloud Infrastructure (OCI) console. - Convert a Physical Standby ACD to Snapshot Standby ACD
A snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot standby database. - Convert a Snapshot Standby ACD to Physical Standby ACD
A snapshot standby database will automatically convert back to a physical standby database after 7 days. - Rotate CDB Encryption Key
- Managing a Standby Autonomous Container Database
Enabling Autonomous Data Guard on an Autonomous Container Database creates a standby (peer) Autonomous Container Database that provides data protection, high availability, and facilitates disaster recovery for the primary database. - Perform a Failover to Standby Autonomous Container Database
Initiate a failover operation by using the Data Guard association of the standby database. - Perform a Switchover to Standby or Primary Autonomous Container Database
Initiate a switchover operation by using the Data Guard association of the primary database. - Reinstate Data Guard Enabled Standby Autonomous Container Database
After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby. - Terminate a Data Guard Enabled Primary Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system. - Terminate a Data Guard Enabled Standby Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system. - Operations Performed Using the APIs
Learn how to use the API to manage Autonomous Data Guard Enabled Autonomous Container Database.
Create an Autonomous Data Guard Enabled Autonomous Container Database
Follow these steps to create an Autonomous Data Guard Enabled Autonomous Container Database on an Oracle Exadata Cloud@Customer system.
For better management and sharing of the underlying SGA/memory resources, Oracle recommends that all Autonomous Databases configured for In-Memory be in the same Autonomous Container Database.
Minimum Resource Requirements
To create one Autonomous Container Database, you need at least:
- 2 OCPUs or 8 ECPUs
- 50 GB local storage
View Details of a Data Guard Enabled Primary or Standby Autonomous Container Database
Follow these steps to view detailed information about a primary or standby Autonomous Container Database on an Oracle Exadata Database Service on Cloud@Customer system.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Container Databases.
- In the list of Autonomous Container Databases, click the display name of the database you wish to view details.
- In the Autonomous Container Database Details page, check the Autonomous Data Guard association status and peer database state.
- To change the protection mode and Fast-Start Failover (FSFO) lag limit of the
primary database, select Update Autonomous Data Guard from the More
Actions drop-down list.
- In the resulting Update Autonomous Data Guard dialog, make changes and click Save Changes.
- Under Resources, click Autonomous Data Guard to view association details.
Edit Autonomous Container Database Backup Settings
If automatic backups were disabled while provisioning an Autonomous Container Database (ACD), you can enable them later from the Oracle Cloud Infrastructure (OCI) console.
Convert a Physical Standby ACD to Snapshot Standby ACD
A snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot standby database.
A snapshot standby database receives and archives redo data received from a primary
database. Redo data received from a primary database, however, is not applied. The
redo data is applied when a snapshot standby database is converted back into a
physical standby database after discarding all local updates to the snapshot standby
database. Once the conversion is complete, the role of the standby ACD will change
to SNAPSHOT_STANDBY
. You can perform DDL and DML operations on all
ADBs in the SNAPSHOT_STANDBY
ACD.
- A snapshot standby will automatically convert back to physical standby after 7 days.
- Automatic Backups will not be taken on a snapshot standby.
Convert a Snapshot Standby ACD to Physical Standby ACD
A snapshot standby database will automatically convert back to a physical standby database after 7 days.
The system displays a banner with the actual date when the snapshot standby database will convert back to a physical standby database. Database role on all the ADBs in that ACD will also change accordingly. Banner message about automatic conversion will be available only on ACDs.
Rotate CDB Encryption Key
Follow these steps to rotate the TDE Master key. On key rotation, the ACD life cycle goes through the regular updating state and returns to available.
You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.
You can rotate both Oracle-managed and customer-managed encryption keys.
- Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
- Click Autonomous Container Databases.
- In the list of Autonomous Container Databases, click the display name of the primary or standby database you wish to view details.
- On the Autonomous Container Database Details page, click Rotate Encryption Key.
- On the Rotate Encryption Key dialog, click Rotate Encryption Key.
Managing a Standby Autonomous Container Database
Enabling Autonomous Data Guard on an Autonomous Container Database creates a standby (peer) Autonomous Container Database that provides data protection, high availability, and facilitates disaster recovery for the primary database.
If the primary Autonomous Container Database becomes unavailable because of a region failure, a failure of the Autonomous Exadata Infrastructure, or the failure of the Autonomous Container Database, itself, then it automatically fails over to the standby Autonomous Container Database if Automatic Failover is enabled. The role of the failed primary database becomes Disabled Standby and, after a brief period of time, the standby database assumes the role of the primary database.
Besides hardware failures and regional outages, the following table lists database health conditions that also trigger automatic failover:
Table 6-8 Database Health Condition
Database Health Condition | Description |
---|---|
Datafile Write Errors | The system initiates a fast-start failover if write errors occur in any data files, including temp files, system data files, and undo files. |
Corrupted Dictionary | Dictionary corruption of a critical database. Currently, this state can be detected only when the database is open. |
Corrupted Controlfile | Controlfile is permanently damaged because of a disk failure. |
- After automatic failover concludes, a message displays on the details page of the disabled standby database advising you that failover has occurred.
- Automatic failover is optional while configuring Autonomous Data Guard. You can enable or disable automatic failover after configuring Autonomous Data Guard.
- The
FastStartFailoverLagLimit
configuration attribute establishes an acceptable limit, in seconds, up to which the standby database can fall behind the primary database, with respect to the redo applied. If the limit is reached, then a fast-start failover does not occur. This attribute is used when fast-start failover is enabled and the configuration is operating in maximum performance mode.TheFastStartFailOverLagLimit
attribute:- Has a default value of 30 seconds
- Cannot be configured
- Is only applicable when in maximum performance protection mode
After the service resolves the issues with the former primary Autonomous Container Database, you can perform a manual switchover to return both databases to their initial roles.
- Manually switching over a primary database to a standby database
- Manually failing over a primary database to a standby database
- Reinstating a primary database to standby role after failover
- Terminating a standby database
Perform a Failover to Standby Autonomous Container Database
Initiate a failover operation by using the Data Guard association of the standby database.
Perform a Switchover to Standby or Primary Autonomous Container Database
Initiate a switchover operation by using the Data Guard association of the primary database.
- You can perform Switchover only when both primary and standby are in available state.
- You cannot perform switchover if patching or maintenance is in progress on primary or standby.
- You cannot perform switchover operation If the standby ACD is in snapshot standby mode.
- After the switchover, the maintenance preference for the new standby and primary will remain the same as the old standby and primary.
Reinstate Data Guard Enabled Standby Autonomous Container Database
After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby.
After the operations team correct the cause of failure, you can reinstate the failed database as a functioning standby for the current primary by using its Data Guard association. you can reinstate the failed database as a functioning standby for the current primary by using its Data Guard association.
Terminate a Data Guard Enabled Primary Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system.
You must terminate all Autonomous Databases within a container database before you can terminate the container database itself. Terminating Autonomous Container Database will disable Autonomous Data Guard, which affects high availability and disaster recovery of your Autonomous Databases.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Container Databases.
- In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
- In the Autonomous Container Database Details page, select Terminate from the More Actions drop-down list.
- Click Terminate.
- In the confirmation dialog, type the name of the Autonomous Container Database, and then click Terminate Autonomous Container Database.
Terminate a Data Guard Enabled Standby Autonomous Container Database
Follow these steps to terminate an autonomous container database on an Oracle Exadata Cloud@Customer system.
You can terminate a standby Autonomous Container Database even if there are standby Autonomous Databases inside it. However, you cannot terminate standby Autonomous Databases inside a standby Autonomoous Container Database. To terminate a standby Autonomoous Database, you must first terminate the primary Autonomous Database. Terminating Autonomous Container Database will disable Autonomous Data Guard, which affects high availability and disaster recovery of your Autonomous Databases.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Container Databases.
- In the list of Autonomous Container Databases, click the display name of the infrastructure resource you are interested in.
- In the Autonomous Container Database Details page, select Terminate from the More Actions drop-down list.
- Click Terminate.
- In the confirmation dialog, type the name of the Autonomous Container Database, and then click Terminate Autonomous Container Database.
Operations Performed Using the APIs
Learn how to use the API to manage Autonomous Data Guard Enabled Autonomous Container Database.
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".
The following table lists the REST API endpoints to manage Autonomous Data Guard Enabled Autonomous Container Database.
Operation | REST API Endpoint |
---|---|
Creates Autonomous Container Databases (update to the existing API) |
|
View details of the specified Autonomous Container Database |
|
View a list of Autonomous Container Databases with Autonomous Data Guard associations |
|
Fetch details of an Autonomous Container Database Autonomous Data Guard associations |
|
Fail over the standby Autonomous Container Database identified by the
|
|
Switch over the primary Autonomous Container Database of an
Autonomous Data Guard peer association to standby role. The standby
Autonomous Container Database associated with
|
|
Reinstate a disabled standby Autonomous Container Database identified
by the |
|
View a list of the Autonomous Data Guard-enabled databases associated with the specified Autonomous Database. |
|
Fetch details of an Autonomous Database Autonomous Data Guard associations |
|
Fetches details such as peer database role, lag time, transport lag, and state |
|
Enabling Autonomous Data Guard on an Autonomous Database
Autonomous Databases inherit Data Guard settings from the parent container database.
- View Autonomous Data Guard Enablement
Autonomous Data Guard settings are configured on the Autonomous Container Databases in which the databases are running. - Create an Autonomous Data Guard Enabled Autonomous Database
- View Details of a Data Guard Enabled Primary or Standby Autonomous Database
Follow these steps to view detailed information about a primary or standby Autonomous Database on an Oracle Exadata Database Service on Cloud@Customer system. - Rotate ADB Encryption Key
View Autonomous Data Guard Enablement
Autonomous Data Guard settings are configured on the Autonomous Container Databases in which the databases are running.
Parent topic: Enabling Autonomous Data Guard on an Autonomous Database
Create an Autonomous Data Guard Enabled Autonomous Database
You cannot create an Autonomous Database for Developers instance on an Autonomous Data Guard-enabled container database.
Related Topics
Parent topic: Enabling Autonomous Data Guard on an Autonomous Database
View Details of a Data Guard Enabled Primary or Standby Autonomous Database
Follow these steps to view detailed information about a primary or standby Autonomous Database on an Oracle Exadata Database Service on Cloud@Customer system.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to view details.
- In the Autonomous Database Details page, check the Autonomous Data Guard association status and peer database state.
- Under Resources, click Autonomous Data Guard to view association details.
Parent topic: Enabling Autonomous Data Guard on an Autonomous Database
Rotate ADB Encryption Key
Follow these steps to rotate the TDE Master key. On key rotation, the ADB life cycle goes through the regular updating state and returns to available.
You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.
You can rotate both Oracle-managed and customer-managed encryption keys.
- Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to view details.
- On the Autonomous Database Details page, from the More Actions drop-down list, select Rotate Encryption Key.
- On the Rotate Encryption Key dialog, click Rotate Encryption Key.
Parent topic: Enabling Autonomous Data Guard on an Autonomous Database
Maintenance Scheduling and Patching Data Guard Enabled Autonomous Container Database
Follow these steps to change the maintenance schedule of a Data Guard enabled Autonomous Container Database.
- Configure Automatic Maintenance Schedule for a Data Guard Enabled Autonomous Container Database
- View the Next Scheduled Maintenance Run of a Data Guard Enabled Autonomous Container Database
- View the Maintenance History of a Data Guard Enabled Autonomous Container Database
- Immediately Patch a Data Guard Enabled Autonomous Container Database
- Reschedule or Skip scheduled Maintenance for Data Guard Enabled Autonomous Container Database
Immediately Patch a Data Guard Enabled Autonomous Container Database
Patching primary immediately will result in standby being patched first, if standby is not already patched.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Container Databases, click the display name of the Autonomous Container Database that you want to patch.
- On the Autonomous Container Database Details page, in the Maintenance section, click the View link in the Next Maintenance field to display the Maintenance page for the Autonomous Container Database that you want to patch.
- In the Autonomous Container Database section, click Patch Now in the Scheduled Start Time field to display the Run Maintenance dialog.
- Click Patch Now to start the patching operation.