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!

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.

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.

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.

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.

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.