Manage Primary and Standby Databases in an Autonomous Data Guard Configuration
Learn how to manage primary and standby databases in an autonomous data guard configuration.
When you create an Autonomous AI 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 AI Database.
Note: Because two Autonomous AI Databases are created when you use Autonomous Data Guard, twice the number of CPU 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 AI 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 AI 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 CPU 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 AI 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 clicking Autonomous Data Guard.
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 does not have sufficient capacity to keep up with the redo records coming from the primary database. To resolve this situation, scale up the CPUs of the database, as described in Add CPU or Storage Resources to a Dedicated Autonomous AI 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.