Oracle Cloud Infrastructure Documentation

Managing Primary and Standby Databases in an Autonomous Data Guard Configuration

Learn how to mange primary and standby databases in an autonomous data guard configuration.

When you create an Autonomous Database in an Autonomous Container Database that has Autonomous Data Guard enabled, two completely separate copies of your database are created: one in a primary container database, and one (a synchronized copy) in a standby container database. Then, should the primary container database become unavailable, Autonomous Data Guard automatically converts the standby container database to the primary container database and, as such, it begins servicing application connections to your Autonomous Database.

Note

Because two autonomous databases are created when you use Autonomous Data Guard, twice the number of OCPU and storage resources are used, half for the primary database and half for the standby database.

These two databases, often called peer databases of each other, are identified by the labels Primary and Standby in the list of Autonomous Databases and on the Details page for the database.

For information about how fleet administrators create and manage Autonomous Container Databases with Autonomous Data Guard enabled, see Manage Autonomous Data Guard.

Management Operations on Primary and Standby Databases

Because the two databases are linked and synchronized, some of the management operations you perform on Autonomous Databases work differently on the primary and standby databases in an Autonomous Data Guard configuration as compared to standard databases. The following list describes these differences.

  • Scale up, Scale down, and auto-scaling

    The two peer databases must have the same OCPU count, storage size, and auto-scaling setting. Therefore, you can only scale up, scale down and change auto-scaling settings from the Details page of the primary database. Changes you make affect both the primary and standby databases.

  • Stop, Start and Restart

    The lifecycle status of the two peer databases is kept synchronized. Therefore, you can only stop, start and restart the database from the Details page of the primary database. The operation you perform affects both the primary and standby databases.

  • Back up manually

    You can manually back up the primary and standby databases separately and independently, just as though they were standard databases.

  • Restore

    You can restore and recover the database only from the Details page of the primary database.

  • Clone

    You can clone the database only from the Details page of the primary database.

  • Rotate the encryption key

    You can rotate the encryption keys of the primary and standby databases separately and independently, just as though they were standard databases.

  • Move to a different compartment

    You can move the primary and standby databases to different compartments separately and independently, just as though they were standard databases.

  • Terminate

    You can terminate the database only from the Details page of the primary database.

Accessing Standby Databases from Client Applications

When using Autonomous Data Guard, 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 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 primary or standby 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.