Oracle Cloud Infrastructure Documentation
Try Free Tier

Autonomous Data Guard Notes

Provides notes for using Autonomous Database with an Autonomous Data Guard standby database.

  • You cannot connect to a Standby database until it is made the Primary by a failover or a switchover. Thus, a Standby database cannot be opened for read-only access and cannot be used to offload queries from a Primary database.

  • Autonomous Data Guard is available with the Data Warehouse and Transaction Processing workload types. Autonomous Data Guard is not available with the JSON and APEX workload types.

  • Autonomous Data Guard is not available with Always Free Autonomous Databases.

  • Autonomous Database does not provide access to a local Standby database:

    • You perform all operations, such as scaling up the ECPU count (OCPU count if your database uses OCPUs) enabling compute auto scaling on the Primary database and Autonomous Database performs the same actions on the local Standby database. Likewise, you only perform actions such as stopping or restarting the database on the Primary database.

    • A local Standby database is not available for use as a read-only database.

  • The Number of ECPUs (OCPUs if your database uses OCPUs) allocated graph and the CPU utilization graph on the Database Dashboard card in Database Actions displays the ECPUs (OCPUs if your database uses OCPUs) allocated and the CPUs utilization for the Primary database. These graphs do not include information about a local Standby database or about a remote Standby database.

    The CPU Utilization metrics on the Oracle Cloud Infrastructure Console metrics page display the CPU utilization for the Primary database. Other metrics on this page also apply to the Primary database. These metrics do not include information about the local Standby database or remote Standby database.

  • After a switchover or failover to a peer database, the peer database becomes the Primary and the graphs on the Database Dashboard in Database Actions and the Oracle Cloud Infrastructure Console metrics page display information about the Primary database. The graphs and metric do not contain information about the database that was the Primary before the switchover or failover operation.

  • Automatic Failover to a local Standby is disabled during a Restore in Progress operation.

  • Automatic Failover to a local Standby disabled when Upgrading a Database.

  • When the Lifecycle state field for the Primary database shows Stopped, standby databases are also stopped. You may still perform a switchover when the Primary database is Stopped.

Cross-Region Autonomous Data Guard Notes

The following are restrictions and limitations when you enable Autonomous Data Guard with a cross-region (remote) standby database:

  • To disable Autonomous Data Guard with a cross-region standby database, you terminate the remote Standby database. See Terminate a Cross-Region Standby Database for more information.

  • When a private endpoint is enabled or disabled on the Primary database, any previously configured Access Control List (ACL) on the Standby is enabled and the values are cleared. You must reset and verify the ACL on the Standby database after you disable a private endpoint on the Primary.

  • You perform most operations, such as scaling up the ECPU count (OCPU count if your database uses OCPUs) and enabling compute auto scaling on the Primary database and Autonomous Database performs the same actions on the remote Standby database. Likewise, you only perform actions such as stopping or restarting the database on the Primary database.

  • You can perform certain operations, such as configuring private endpoints on a remote Standby database.

  • You can modify network configuration for ACLs on a remote Standby database. See Manage Remote Peer Network ACLs for more information.

  • A remote Standby database is not available for use as a read-only database.

  • Oracle Data Safe can be enabled on a database that has a cross-region Standby database enabled, but it only monitors the database within its region, and cannot monitor the standby in the event of a switchover or a failover.

  • When you allow TLS authentication for the Primary database, Autonomous Data Guard enables TLS authentication in the cross- region Standby. Thus, when Autonomous Data Guard is enabled with a remote Standby, you can only allow TLS connections on the Primary if both the Primary and the remote Standby are configured to support TLS connections. That is, the Primary and the remote Standby must either be configured with ACLs or with a private endpoint. See Network Configuration Prerequisites to Allow TLS Authentication for more information.

  • See for the following information on using customer-managed keys with Autonomous Data Guard

  • The BYOL ECPU limit you set on an Autonomous Data Guard Primary database does not apply to a cross-region or cross-tenancy Autonomous Data Guard Standby database. On a cross-region or cross-tenancy Standby you can independently set the BYOL ECPU limit, as required. Setting a value for BYOL License limit limits how many ECPUs will be covered by BYOL licenses.

    See Autonomous Data Guard Cross-Region BYOL Licensing for more information.

  • When you enable Autonomous Data Guard with a cross-region standby database, the wallets for the primary and the standby specify different database hostnames and use different connection strings. Oracle recommends that applications use the connection string or wallet downloaded from the same region as the primary database.

    If you need to use a single connection string or wallet containing both the primary and the standby database hostnames, you may construct this manually.

    To manually construct a wallet that contains both the primary and the remote database connections strings:

    1. From the primary database's Oracle Cloud Infrastructure Console, click Database connection to download the primary's wallet.zip.

    2. From the remote standby database's Oracle Cloud Infrastructure Console, click Database connection to download the standby's wallet.zip.

    3. Unzip both wallet files and open the two tnsnames.ora files.

    4. Copy the remote database's connect descriptor into the primary database's connection string in the primary's tnsnames.ora file using your preferred retry delays.

    5. Zip the updated primary database wallet folder.

    With this updated tnsnames.ora, your primary database connection strings in the updated wallet.zip will contain both the primary and the standby hostnames, to support failover. An application using the updated wallet attempts to connect and retries connecting to the first listed database hostname, and if that connection fails due to the database being Unavailable, the application then automatically attempts to connect to the second database hostname.

    For example, if your Autonomous Data Guard is setup with the primary in Ashburn (IAD) and a cross-region standby in Phoenix (PHX), Oracle recommends that your mid-tier applications running in IAD use the connection string or wallet from that of the primary database in IAD, and your corresponding applications running in PHX use the connection string or wallet from that of the standby database in PHX. For a regional failover or switchover, Oracle recommends failing over both your database and your application or mid-tier, for optimum performance and to minimize any cross-regional latency.

    For example:

    a6gxf2example9ep_high = (description_list= 
     (failover=on) (load_balance=off) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))

a6gxf2example9ep_low = 
     (description_list= (failover=on) (load_balance=off) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))

a6gxf2example9ep_medium = 
     (description_list= (failover=on) (load_balance=off) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
     (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))

Was this article helpful?