Convert Cross-Region Peer to Snapshot Standby
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.
You can create a snapshot standby for a cross-region peer. You cannot create a snapshot standby for a local disaster recovery peer.
- 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
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.
Parent topic: Convert Cross-Region Peer to Snapshot Standby
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.
Parent topic: About Disaster Recovery Snapshot Standby Databases
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. |
Parent topic: About Disaster Recovery Snapshot Standby Databases
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.
When a snapshot standby is not reconnected within 48 hours, the snapshot standby automatically reconnects to the source database.
Parent topic: About Disaster Recovery Snapshot Standby Databases
Convert Cross-Region Disaster Recovery Peer to a Snapshot Standby
You can convert a cross-region disaster recovery peer to a snapshot standby.
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.
Parent topic: Convert Cross-Region Peer to 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.
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.
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.
Parent topic: Convert Cross-Region Peer to Snapshot Standby