The Autonomous Data Guard feature of Autonomous Database on dedicated infrastructure enables you to keep your critical production databases available to mission critical applications despite failures, disasters, human error, or data corruption. This kind of capability is often called disaster recovery.
About Autonomous Data Guard
Autonomous Data Guard creates and maintains two completely separate copies of your database: a primary database that your applications connect to and use, and a standby database that is a synchronized copy of the primary database. Then, should the primary database become unavailable for any reason, Autonomous Data Guard automatically converts the standby database to the primary database and, as such, it begins servicing your applications.
The primary and standby databases are often called peer databases of each other.
Note:Applications must be configured to use Transparent Application Continuity (TAC) to gain the full benefit of the database availability features provided by Autonomous Data Guard.
The following diagram shows how the standby database is kept synchronized with the primary database.
Changes made to the primary database are recorded in the primary database's redo log. Autonomous Data Guard transmits these redo records as a stream over the network to the standby database's redo log. Then, the standby database applies these records to the standby database. In this way, the standby database is kept synchronized with the primary database.
Synchronization is nearly instantaneous, but, as the process just described implies, there are two operations that consume time: transporting the redo records to the standby database and applying the redo records to the standby database. The first of these is called the transport lag, and the other is called the apply lag. You can view current lag values for a dedicated Autonomous Database from the database's Details page by choosing Autonomous Data Guard Assocations under Resources in the side menu. You can view current lag values across all the dedicated Autonomous Databases in a container database from the container database's Details page in a similar fashion.
Configuring Autonomous Data Guard
In Oracle Autonomous Database on dedicated infrastructure, you configure and manage Autonomous Data Guard at the Autonomous Container Database level.
When you create an Autonomous Container Database, you select the Enable Autonomous Data Guard option and then provide details about the standby database, most notably the Autonomous Exadata Infrastructure resource you want it created in and the protection mode you want to use. For information about the choices you have regarding these two details, see Choosing Autonomous Data Guard Configuration Options.
Role Transitions and Operations
After an Autonomous Container Database is created, you can change the role of the peer databases using either a switchover or a failover operation. Additionally, should the primary database become unavailable for any reason, Autonomous Data Guard automatically performs a failover operation.
A switchover is a role reversal between the primary database and its standby database. A switchover ensures no data loss. During a switchover, the primary database transitions to the standby role, and the standby database transitions to the primary role. In general, you perform a switchover operation to restore the roles of peer databases to their original configuration after a failed primary database has been reinstated as a standby. To perform a switchover operation, see Switch Roles in an Autonomous Data Guard Configuration.
A failover is when the primary database is unavailable. The failover results in a transition of the standby database to the primary role. In general, you do not need to perform a failover operation manually. However, in the rare case when an automatic failure operation fails, you can perform a manual failover as described in Fail Over to the Standby in an Autonomous Data Guard Configuration.
The availability and status of the database after a failover operation is characterized by two recovery objectives:
- Recovery Time Objective (RTO). The RTO the maximum amount of time required for the database to become available to applications after a failover, and is related to some degree to the apply lag at the time of the failure. For Autonomous Data Guard, the RTO is seconds up to two minutes.
- Recovery Point Objective (RPO). The RPO is the maximum duration of potential data loss from the failed primary database, and is related to some degree to the transport lag at the time of the failure. For Autonomous Data Guard, the RPO is near-zero.
When a failed primary database becomes available again, its role is set to Disabled Standby. At this point, you re-enable it by performing a reinstate operation. To perform a reinstate operation, see Reinstate the Disabled Standby in an Autonomous Data Guard Configuration.
Accessing Standby Databases from Client Applications
In an Autonomous Data Guard configuration, your client applications normally connect to and perform operations on the primary database.
In addition to this normal connectivity, Autonomous Data Guard provides you the option to connect client applications that perform only read-only operations to the standby database. To take advantage of this option, client applications connect to the database using database service names that include "_RO" (for "read only"), as described in Predefined Database Service Names for Autonomous Transaction Processing Dedicated Databases and Predefined Database Service Names for Autonomous Data Warehouse Dedicated Databases.
Monitoring Lag Times
As your databases that use Autonomous Data Guard are running, you can monitor transport lag and apply lag times from the database's (or container database's) Details page by choosing Autonomous Data Guard Assocations under Resources in the side menu.
You should expect to see minor fluctuations over time as the workload on your database ebbs and flows. However, if you notice a continuing upward trend in lag time, you can take these actions to resolve the situation:
- Upward Trend in Apply Lag. A continuing upward trend in apply lag indicates that the standby database doesn't have sufficient capacity to keep up with the redo records coming from the primary database. To resolve this situation, scale up the OCPUs of the database, as described in Add CPU or Storage Resources to a Dedicated Autonomous Database.
- Upward Trend in Transport Lag. A continuing upward trend in transport lag indicates a network performance issue. Oracle Cloud operations staff constantly monitors network performance, so you should see the situation resolve itself without you taking any action. However, if you want, you can bring the situation to the operations staff by raising a service request, as described in Create a Service Request in My Oracle Support.
Choosing Autonomous Data Guard Configuration Options
When you create an Autonomous Container Database with Autonomous Data Guard enabled, you specify which Autonomous Exadata Infrastructure resource you want the standby database created in, and you specify which data protection mode you want to use.
You have three choices when specifying which Autonomous Exadata Infrastructure resource to use for the standby:
- In a different region from the primary database's Autonomous Exadata
This choice provides the highest level of protection against disasters, including a catastrophic loss of external network connectivity or power to an entire region.
To make best use of this cross-region protection, your application tier also needs to be configured to support cross-region protection. Therefore, Oracle recommends that you choose this option if your application tier is already configured this way or if you are willing to reconfigure it to support cross-region protection.
If you choose to locate the standby database in a different region, Oracle recommends that you use the Maximum Performance protection mode.
- In a different availability domain (AD) from the primary database's
Autonomous Exadata Infrastructure
This choice provides a high level of protection against disasters, including a catastrophic loss of external network connectivity or power to an availability domian within a region.
This choice provides a good balance between data protection and simplicity of configuration in your application tier.
If you choose to locate the standby database in a different availability domain, Oracle recommends that you use the Maximum Availability protection mode.
- In the same availability domain (AD) as the primary database's Autonomous
This choice provides a minimum level of protection against disasters, and Oracle recommends that you not choose it.
If the primary database's Autonomous Exadata Infrastructure is in a region that has only one availability domain, Oracle recommends that you use the "in a different region" option.
If you do choose to locate the standby database in the same availability domain, Oracle recommends that you use the Maximum Availability protection mode
About Protection Modes
Autonomous Data Guard provides these data protection modes:
Maximum Availability. This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database.
The primary database does not commit transactions until it receives acknowledgement that the data has been received on the standby, (not that it has been written to disk). If the primary database does not receive this acknowledgement within 30 seconds, it operates as if it were in maximum performance mode to preserve primary database availability until it again receives acknowledgements in a timely fashion.
This protection mode ensures zero data loss except in the case of certain double faults, such as failure of a primary database after failure of the standby database.
Maximum Performance. This is the default protection mode. It provides the highest level of data protection that is possible without affecting the performance of the primary database.
The primary database commits transactions as soon as all redo data generated by those transactions has been written to its online redo log. It also sends redo data to the standby database, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database.
This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.
For more information about protection modes in Oracle Data Guard (which underlies the Autonomous Data Guard feature), see Oracle Data Guard Protection Modes in Oracle Data Guard Concepts and Administration.
How Autonomous Data Guard Affects Standard Management Operations
In some cases, the standard management operations you perform on Autonomous Container Databases work differently on the primary and standby container databases in an Autonomous Data Guard configuration as compared to standard container databases. The following list describes these differences.
You can restart primary and standby container databases separately and independently, just as though they were standard container databases.
- Change the maintenance schedule
Maintenance scheduling of a primary container database and its standby are linked: maintenance on the standby is performed a number of days before maintenance on the primary. The default is 7 days; you can choose from 1 to 7 days when you create the primary container database or later by editing its Maintenance Details.
- Change the maintenance type
The maintenance type of a primary container database and its standby must be the same. You choose the the maintenance type for both the primary and standby when you create the primary container database or later by editing its Maintenance Details.
- Manage scheduled maintenance
You can manage scheduled maintenance of a primary container database and its standby separately. However, because maintenance of the two are linked, you must perform scheduled maintenance on the standby before the primary if you choose to override the scheduled maintenance time.
- Rotate the encryption key
You can rotate the encryption keys of primary and standby container databases separately and independently, just as though they were standard container databases.
- Move to a different compartment
You can move primary and standby container databases to different compartments separately and independently, just as though they were standard container databases. However, as with standard container databases, you should exercise extreme caution when moving a container database to ensure that the container database remains accessible to the appropriate groups of cloud users.
You can terminate primary and standby container databases separately. However, the consequences of terminating a primary container database and terminating a standby container database differ:
- Terminating a primary container database terminates both the primary and standby container databases. You cannot terminate a primary container database that contains autonomous databases.
- Terminating a standby container database terminates the standby container database and removes the Autonomous Data Guard configuration from the primary container database, making it a standard container databae.