Convert Cross Region Peer to Snapshot Standby

A cross-region peer can be converted to a snapshot standby. This converts the peer to a read-write database for up to two days.

Snapshot standby CPU usage is billed based on the base CPU count and any additional CPU usage if compute auto scaling is enabled. The number of base CPUs is specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count or OCPU count field on the Oracle Cloud Infrastructure Console.

Snapshot standby storage usage is billed based on the storage of the snapshot standby plus 1 x the storage of the source primary database.

• About Disaster Recovery Snapshot Standby Databases
  Converting a disaster recovery peer to a snapshot standby opens the database in read-write mode and the cross-region disaster recovery peer temporarily stops refreshing data from the source database.
• Convert Cross Region Disaster Recovery Peer to a Snapshot Standby
  You can convert a cross-region disaster recovery peer to a snapshot standby.
• Convert Snapshot Standby Back to a Cross-Region Disaster Recovery Peer
  You can manually convert a snapshot standby back to a disaster recovery peer for the primary (source database). After the converting back, the snapshot standby returns to its role as a disaster recovery standby.

About Disaster Recovery Snapshot Standby Databases

Converting a disaster recovery peer to a snapshot standby opens the database in read-write mode and the cross-region disaster recovery peer temporarily stops refreshing data from the source database.

While operating as a snapshot standby, updates from the source database are still sent to the snapshot standby, and you are protected if the source database region were to encounter a failure, however the updates are not applied to the snapshot standby until the database is converted back to a disaster recovery peer.

• Snapshot Standby Features
  Provides information on snapshot standby features.
• Snapshot Standby Operations
  After you create a snapshot standby you can perform almost all database operations on the snapshot standby. There are some operations that are not allowed on a snapshot standby.
• Snapshot Standby Reconnect Time
  A banner on the Oracle Cloud Infrastructure Console indicates the date and time when the snapshot standby automatically reconnects to the source database. At the time indicated on the banner, Autonomous Database converts a snapshot standby back to the Standby role.

Snapshot Standby Features

Provides information on snapshot standby features.

While the database is in the Snapshot standby role:

• By converting a cross-region disaster recovery peer, you can use the snapshot standby for testing and querying the data in the peer. This allows you to test with no downtime on the primary (source) database, compared to testing by using switchover to the remote peer.

• You can use a snapshot standby to completely test your disaster recovery environment, including making any changes required to verify your standby environment, such as the mid-tier configuration. Using a snapshot standby you can make configuration changes or perform DML operations on the database as needed for complete testing and verification of the standby environment.

Reconnecting a snapshot standby to the primary (source database):

• Reconnect to the primary, source database, when you are done with the tasks that require the snapshot standby to be open for read-write operations. If you do not manually reconnect within two days, the snapshot standby automatically reconnects to the primary.

• Oracle recommends you convert a snapshot standby back to a disaster recovery peer as soon as you are done with the operations that require the standby to be open for read-write operations. When you convert back to a to a disaster recovery peer, the accumulated changes from the source database are applied on the peer. If you keep the disaster recovery peer open as a snapshot standby for a longer period, assuming there are ongoing changes on the primary during this time, it takes longer to convert back to a disaster recovery peer.

When the snapshot standby reconnects to the primary database, Autonomous Database performs the following actions:

• The disaster recovery type you were using, and any associated billing returns to the type it was before you performed the convert disaster recovery peer to snapshot standby. That, the disaster recovery peer returns to the same type of disaster recovery peer, either Backup-Based Disaster Recovery (Backup copy) or Autonomous Data Guard, as shown in the DR Type column in the Disaster Recovery area.

• Any changes on the snapshot standby from the time it was converted to a snapshot standby, until the time it reconnects to the source are discarded. This means all changes, including metadata, that is inserted, updated, or deleted while the database operates as a snapshot standby are lost (discarded) when the snapshot standby reconnects to its source database.

• All changes that occurred on the primary are replicated to the remote region while the database operates as a snapshot standby, but the changes are not applied to the snapshot standby. The changes that occur on the primary during this period are applied to the snapshot standby when it is converted back to a disaster recovery peer.

• On the Oracle Cloud Infrastructure Console, the role updates from Role: Snapshot standby to Role: Standby or Role: Backup copy, depending on the disaster recovery type.

Snapshot Standby Operations

After you create a snapshot standby you can perform almost all database operations on the snapshot standby. There are some operations that are not allowed on a snapshot standby.

Operation	Description
Convert to Snapshot Standby	You can convert a cross-region peer to a snapshot standby. See Convert Cross Region Disaster Recovery Peer to a Snapshot Standby for the steps to convert a peer database to snapshot standby.
Start or Restart	When a snapshot standby is stopped, as indicated by the Lifecycle State Stopped, you can start the database. When a snapshot standby is available, as indicated by the Lifecycle State Available, you can restart the database or stop the database.
Convert Snapshot Standby Back to Disaster Recovery Peer	When a snapshot standby is in the Snapshot standby role, the database operates as a read-write database. A snapshot standby has a two day (48 hour) limit up to which it can stay in the Snapshot standby role. If you do not manually convert the snapshot standby back within two days, the snapshot standby automatically converts back to a disaster recovery peer. See Convert Snapshot Standby Back to a Cross-Region Disaster Recovery Peer for more information.
Stop	When a snapshot standby is stopped, database operations are not available and charging for CPU usage on the snapshot standby stops.
Terminate	You are not allowed to terminate a snapshot standby. You can reconnect the snapshot standby to the primary. See Convert Snapshot Standby Back to a Cross-Region Disaster Recovery Peer for more information.
Create Refreshable Clone	You are not allowed to create a refreshable clone on a snapshot standby.
Disaster Recovery Peer	You are not allowed to add an Autonomous Data Guard standby database or a Backup-Based Disaster Recovery peer to a snapshot standby.

Snapshot Standby Reconnect Time

A banner on the Oracle Cloud Infrastructure Console indicates the date and time when the snapshot standby automatically reconnects to the source database. At the time indicated on the banner, Autonomous Database converts a snapshot standby back to the Standby role.

Description of the illustration adb_dr_snapshot_reconnect_adg.png

Note:

When a snapshot standby is not reconnected within 48 hours, the snapshot standby automatically reconnects to the source database.

Convert Cross Region Disaster Recovery Peer to a Snapshot Standby

You can convert a cross-region disaster recovery peer to a snapshot standby.

Note:

All data, including metadata, that is inserted, updated, or deleted in the database during the disconnect period will be lost when a snapshot standby reconnects to its source database. All changes that occur on the primary during the disconnect period are applied to the standby when it reconnects to the source database.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload, click one of: Autonomous Data Warehouse or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

1. On the Primary Region Autonomous Database instance, on the Autonomous Database Details page under Resources, select Disaster recovery.
2. Access the remote region peer.

   On the Primary Region Autonomous Database instance the Disaster recovery information area shows the Peer Autonomous Database column.

   Under Peer Autonomous Database column, click the link to access the cross-region peer.

3. On the cross-region peer, from the More actions drop-down list, select Convert to snapshot standby database.
   
   Description of the illustration adb_dr_convert_to_snapshot_adg.png
4. On the Convert to snapshot standby database page, enter the source database name to confirm the disconnect.
5. Click Convert to snapshot standby database.

   The Autonomous Database Lifecycle State changes to Updating.

   Note:

   While you convert to a snapshot standby, the primary database is available for read/write operations. There is no downtime on the primary database.

   When the operation completes, note the following:

   • On the snapshot standby, there is a banner that indicates the date and time when the standby database will automatically reconnect with its source database

   • On the snapshot standby, on the Autonomous Database details page, under Disaster recovery, the Role shows Snapshot standby.

   • On the snapshot standby's source database, on the Autonomous Database details page, when you click Disaster recovery under Resources, the Peer role shows Snapshot standby.

   • On the snapshot standby, you can scale CPU or storage, independent of the source database.

   • When you scale CPU or storage on the primary, the changes to the primary do not affect the snapshot standby until it is converted back to a disaster recovery peer.

Convert Snapshot Standby Back to a Cross-Region Disaster Recovery Peer

You can manually convert a snapshot standby back to a disaster recovery peer for the primary (source database). After the converting back, the snapshot standby returns to its role as a disaster recovery standby.

Note:

All data, including metadata, that is inserted, updated, or deleted in the snapshot standby database during the disconnect period will be lost when the snapshot standby reconnects to its source database.

All changes on the primary that were sent to the snapshot standby but not applied during the disconnect period will be applied to the standby when it reconnects to the source database.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload, click one of: Autonomous Data Warehouse or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

1. On the snapshot standby, from the More actions drop-down list, select Reconnect to source peer database.
   
   Description of the illustration adb_dr_reconnect_to_peer_adg.png
2. On the Reconnect to source peer database page, enter the source database name to confirm the reconnect.
3. Click Convert to disaster recovery peer.

   The Autonomous Database Lifecycle State changes to Updating.

   Note:

   While you reconnect the standby to the source database, the primary (source) database is available for read/write operations. There is no downtime on the primary database.

When the snapshot standby reconnects to the primary database, Autonomous Database does the following:

• The disaster recovery type you were using, and any associated billing returns to the type it was before you performed the convert disaster recovery peer to snapshot standby. That, the disaster recovery peer returns to the same type of disaster recovery peer, either Backup-Based Disaster Recovery (Backup copy) or Autonomous Data Guard, as shown in the DR Type column in the Disaster Recovery area.

• Any changes on the snapshot standby from the time it was converted to a snapshot standby, until the time it reconnects to the source are discarded. This means all changes, including metadata, that is inserted, updated, or deleted while the database operates as a snapshot standby are lost (discarded) when the snapshot standby reconnects to its source database.

• All changes that occurred on the primary are replicated to the remote region while the database operates as a snapshot standby, but the changes are not applied to the snapshot standby. The changes that occur on the primary during this period are applied to the snapshot standby when it is converted back to a disaster recovery peer.

• On the Oracle Cloud Infrastructure Console, the role updates from Role: Snapshot standby to Role: Standby or Role: Backup copy, depending on the disaster recovery type.