How to temporarily open your cross-region disaster recovery peer for read/write with Snapshot Standbys

April 11, 2023 | 5 minute read
Nilay Panchal
Principal Product Manager
Text Size 100%:

Today we're introducing Snapshot Standbys in Autonomous Database (ADB) - A feature that enables you to open up your cross-region disaster recovery (DR) peer temporarily for read-write. When you convert your DR peer database to a snapshot standby, it is fully updateable and while it continues to pull backup/redo data from its remote source database (so you are still DR protected in case the source database region were to go down), it does not apply the data refreshed from its remote source database until it is converted back to a disaster recovery peer. If you are using snapshot standbys on Oracle Database on-premise, this feature on Autonomous Database should look familiar to you!


Snapshot Standby

Following in this blog post, I will detail some use cases for snapshot standby databases as well as describe how to use this feature. Snapshot standby databases offer several use cases for testing and configuring disaster recovery scenarios:

  • You may open, test and verify your disaster recovery peer’s data, when using either backup-based disaster recovery or Autonomous Data Guard, by converting your DR peer to a snapshot standby, without performing a switchover or needing any downtime on the primary database. As mentioned above, the primary database continues to send redo log data to the snapshot standby, the data is simply not applied until it is converted back to a DR peer, so you are still protected from regional outages.
  • Since a snapshot standby can be updated, you may make temporary changes to it that may be required when configuring your application or server for cross-region disaster recovery (such as with your WebLogic (WLS) server)
  • Although I would recommend using cross-region refreshable clones for this use case, your fully updateable snapshot standby may also be used as a temporary dev-test environment to update and query data for analysis, and can be independently scaled up for CPU or storage if needed.

When you are done testing or configuring over your snapshot standby, you may convert the snapshot standby back to a DR peer (It will automatically convert back to a DR peer after 48 hours if you do not do so manually). When you convert your snapshot standby back to a disaster recovery peer, any the updates you make in your snapshot standby will be lost and it will continue to refresh from and follow the source primary database.  Note that we recommend converting your snapshot standby back to a DR peer as soon as you are done needing the standby open for read-write. The longer you keep your DR peer open as a snapshot standby, the longer it would take when converting it back to a DR peer, due to a higher volume of transaction redo updates needing to be applied, accumulated from changes on your source database.


How to convert your cross-region disaster recovery peer to a snapshot standby database

Navigate to your Autonomous Database instance which is a cross-region disaster recovery peer, it can be either disaster recovery type Autonomous Data Guard or Backup-Based Disaster Recovery. If you need details steps on how to enable cross-region disaster recovery on Autonomous Database, follow our disaster recovery LiveLab workshop.

On the Oracle Cloud Infrastructure (OCI) database console, go to your cross-region peer and select Convert to Snapshot Standby database from the More actions drop-down list. Enter the source database name to confirm the conversion.

Convert to snapshot standby


convert to snapshot standby dialog


This may take a several minutes depending on your DR type; converting a backup copy to a snapshot standby instantiates a physical standby database and this would depends on the size of your database.
Note: As with other operations performed on your ADB instance, you may follow the progress of your operation in the Work Requests tab, also on the database console.

Snapshot Standby work request


When converted, you may use your snapshot standby as an Available read-write database; you may now connect to, query and update the database. You may perform most database operations on your snapshot standby (with a few exceptions that may prevent it from converting back to a DR peer such as terminating it, creating a refreshable clone attached to it or adding another disaster recovery peer). You may also scale CPU or storage on your snapshot standby as needed.

Snapshot Standby available


When you are done working with your snapshot standby, you may reconnect your snapshot standby to restart refreshing from its source database by converting it back to a DR peer. To reconnect, select Convert to disaster recovery peer database from the More actions drop-down list and enter the source database name to confirm. If you do not manually reconnect within 48 hours,  your snapshot standby will be automatically converted back to a refreshing DR peer. When you reconnect, any changes made on the snapshot standby are discarded, and any lagging updates made on the source database are applied on the remote peer.

Convert back to DR Peer



Summarizing in conclusion, snapshot standby databases are a useful feature to add to your disaster recovery toolkit that enables you to test your cross-region DR peer and configure your applications by opening up your disaster recovery peer up for updates, without affecting your primary database or your DR protection. Lastly, please refer to the Oracle Cloud documentation for any additional detail you need, that I may not have mentioned here.


Like what I write? Follow me on the Twitter!

Nilay Panchal

Principal Product Manager

Nilay is a principal product manager at Oracle, responsible for adoption and feature development of Oracle's flagship converged cloud database - Autonomous Database. He was previously a developer and data scientist, and has a decade worth of experience in data warehousing, dimensional modeling, search engines and machine learning. A global Carnegie Mellon graduate, he has had the opportunity to work, travel and study in several different countries in various fields. His avocation is music; in his downtime he enjoys playing guitar or piano with a strong cup of chai nearby.

Nilay blogs regularly, and often speaks at cloud and database events. Follow his work on the Twitter @theproductlad

Previous Post

Use JSON Relational Duality with Oracle Database API for Mongo DB

Hermann Baer | 4 min read

Next Post

Send Messages and Query Results from your Autonomous Database to a Microsoft Teams Channel

Can Tuzla | 6 min read
Everything you need to know about data warehousing with the world's leading cloud solution provider