Oracle Cloud Infrastructure Documentation
Try Free Tier

Convert Cross-Region Peer to Snapshot Standby

You can convert a cross-region peer database 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.

You can create a snapshot standby for a cross-region peer. You cannot create a snapshot standby for a local disaster recovery peer.

Parent topic: Autonomous Data Guard Cross-Region and Cross Tenancy Operations

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.

See Oracle Autonomous Database Serverless Features Billing for information on Snapshot standby billing.

  • Snapshot Standby Features and Restrictions
    Provides information on snapshot standby features and restrictions.
  • 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 and Restrictions

Provides information on snapshot standby features and restrictions.

While the database is in the Snapshot standby role, note the following:

  • By converting a cross-region disaster recovery peer to a snapshot standby, you can use the snapshot standby for testing and querying data in the database. 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.

While the database is in the Snapshot standby role, note the following restrictions:

  • The restore operation is not allowed on a snapshot standby database.

  • No new backups are taken or displayed from the time a disaster recovery peer is converted to a snapshot standby. Existing backups that were available before the conversion to a snapshot standby are available. You can only use the backups that are available on a snapshot standby for a clone from backup operation.

  • Cloning from a snapshot standby is only allowed to create a clone the same region as the snapshot standby. You cannot clone a snapshot standby across regions.

Notes for 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.
Disconnect Peer

When you disconnect a snapshot standby, the snapshot standby is disassociated from the primary database. This converts the database from a snapshot database to a standalone database. Following the disconnect operation you are not allowed to reconnect to the Primary.

See Disconnect a Snapshot Standby for more information.

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 Clone

Cloning from a snapshot standby is only allowed to create a clone the same region as the snapshot standby. You cannot clone a snapshot standby across regions.
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 adb_dr_snapshot_reconnect_adg.png follows
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 navigation icon 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.
  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.

    • Cloning is only allowed from a snapshot standby when the clone is in the same region. Cloning across regions is not allowed from a snapshot standby.

    • The clone from backup operation is allowed on a snapshot standby. However, a snapshot standby does not backup any of the temporarily updated data in the read-write snapshot standby. When you clone from a backup on a snapshot standby, the operation creates a clone using a Primary side backup which is replicated to the snapshot standby. See Clone an Autonomous Database Instance for more information.

    • The restore operation is not allowed on 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.

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 navigation icon 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.
  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.

Disconnect a Snapshot Standby

You can disconnect a snapshot standby from the primary database.

When you disconnect a snapshot standby, the snapshot standby is disassociated from the primary database. This converts the database from a snapshot database to a standalone database. Following the disconnect operation you are not allowed to reconnect to the Primary.

The steps to disconnect a snapshot standby are the same as those to disconnect a standby database. See Disconnect a Peer Database for more information.

Notes for disconnecting a snapshot standby.

  • There is no reconnect operation. After you disconnect a snapshot standby you are not allowed to reconnect to the Primary.

  • The disconnect operation for a snapshot standby can only be performed on an Autonomous Database instance that uses the ECPU compute model.

  • The disconnected database keeps any user inserted or updated data that was applied while the database was open in read/write mode as a Snapshot Standby.

    The disconnect operation does not apply any recent logs that were sent from the Primary.

  • After the disconnect operation, the standalone database is no longer associated with the database that was the Primary database. To use the database as a standalone database, you must know the name of the database that was disconnected from the Primary database.

  • After the disconnect operation the database starts taking new backups as a standalone database. Any backups that were associated with the standby database or with the primary database are not available on the standalone database.

Was this article helpful?