Dbvisit's new Standby v10 integrates Reporting Replicas and Test/Dev Snapshots

Reporting Replicas and Test/Dev Snapshots to Enhance Your Oracle Infrastructure

One of the highlights of our new Standby™️ v10 is the integration of Reporting Replicas and Test/Dev Snapshots. This new functionality goes beyond Standby™️’s best practice Disaster Recovery (DR) to provide performance and availability improvements for your Oracle infrastructure.

So let’s take a peek inside this new functionality and what it means!

Reporting Replicas and Test/Dev Snapshots Allow You to Very Quickly Create Space-Efficient Copies of Your Database at a Particular Point in Time

This functionality is integrated into the central console (GUI) which intuitively guides you through steps to create Reporting Replicas or Test/Dev Snapshots.  Using “copy-on-write” technology, snapshots can be created with little space and very quickly – typically within a few minutes.  And once created, the database in the snapshot can be immediately started and used. 

Snapshots Enable Improvement in Primary Database Availability and Performance by Offloading Performance Intensive Tasks to the Standby 

Snapshots offer an excellent opportunity to improve the utilization of your standby infrastructure and in turn increase primary database availability and performance.

Reporting Replicas allow one or more (maximum 4) snapshots to be created at set intervals to make up a single Reporting Replica. This replica is effectively a single logical container and the Oracle Listener is updated with a service that will always point to the latest snapshot within the replica.  As the name suggests, because Replicas provide an easy way to the freshest data they are perfect for reporting or data extraction. 

Test/Dev Snapshots take single snapshots that can be either opened in read-only or read-write. This provides many use cases including: 
•    Development or Test Environments
•    Application Upgrade Testing
•    DR Testing
•    Reporting or Data Extraction

Remember – snapshots should be short lived. The “copy-on-write" technology means they hardly take any space, but over time as updates are applied to the standby database they grow.

Enjoy Complete Flexibility and De-Identify Sensitive Data With the Ability to Execute Custom Actions During Snapshot Creation

Configure your own unique actions to be automatically taken both prior to and immediately after the creation of each snapshot. This is helpful for:
(1) Altering the database state to simulate failure conditions 
(2) The removal of sensitive customer information
(2) Addition of standard dummy test data 

This advanced functionality is still easy to use as example action scripts are provided within Standby™️.

Most Customers Will Be Able to Set up an Environment Compatible With Reporting Replicas and Test/Dev Snapshots Quickly

To be able to use Snapshots there are a few key requirements (full list here in our documentation):
1.    Linux operating system 
2.    Logical Volume Manager (LVM) technology is used 
3.    The standby database or cascading standby database must be fully contained (located) on a single Logical Volume.
If you have difficulty meeting these requirements on your local hardware you could easily establish a new cloud-based environment that can meet these requirements in minutes.