Want to spin up a virtual Oracle Data Guard configuration in a few minutes?
If you are one of the many Oracle Enterprise Edition customers, chances are you may know about Oracle Data Guard. Many Oracle customers use Data Guard for their disaster recovery protection, as well as for high availability through nifty features like Fast-Start Failover (FSFO). Mission critical production databases are often large in size. Creating one or more standby databases when setting up a Data Guard configuration could take a long time, and require a large amount of additional storage.
Let's just say you have passed those pain points of setting up a Data Guard configuration and you have a nice working Data Guard configuration with a few standby databases. What about testing your Data Guard configuration to validate that it meets your requirements? How do you know if you can truly achieve the target failover time in the event of a disaster, or how much data loss you would have post-failover if you choose a particular Data Guard log transport mode?
Today, customers with Data Guard configuration can attempt test failover or switchover to verify these metrics based on their actual production database data. However, this would require scheduled downtime, something that is often not easy to come by with mission critical production databases. Another use case is when you have an application workflow that runs on a Data Guard configuration, where changes are committed on the production primary database and a downstream application reads changes from the standby databases.
In order to test the application without performance impact on the production database, you would need to duplicate the Data Guard configuration. Or more simply, you just want to set up a Data Guard configuration to explore its features. Wouldn't it be nice if you could spin up a sandbox Data Guard configuration based on the actual production database data in just a few minutes, with a fraction of the storage needed?
Use the Delphix magic
First, Delphix magic can only happen to databases that are linked into the Delphix Engine. Once Delphix has ingested your production database, it will continue to sync up incrementally to keep the data up-to-date. From this point onwards, the Delphix magic kicks in: it takes only a few minutes and almost no additional storage to spin up a virtual primary database, another few minutes and an additional small amount of storage to spin up a virtual standby database for this virtual primary database and so on.
Contrary to the time consuming and storage consuming configuration of a physical Data Guard configuration, the configuration of a virtual Data Guard configuration with Delphix is done in minutes with minimal additional storage. Using this Delphix capability, it opens up new opportunities for easy iterations of prototyping or testing a Data Guard configuration, as rebuilding a virtual configuration is a much smaller effort in terms of time and storage compared to rebuilding a physical configuration. The Delphix magic we are referring to here is the provisioning of a virtual database.
To set up a virtual Data Guard configuration to mimic your production Data Guard configuration, you need to first provision a virtual primary database from your production database dSource timeflow. Then you can provision one or more virtual databases from this virtual primary database timeflow, and follow up with some post-provisioning steps to configure these databases to form a virtual Data Guard configuration.
Here is an example of how to set up a virtual Data Guard configuration with one primary and one standby database. The following is a screenshot of the Delphix Engine. I had just provisioned a virtual Data Guard configuration with one primary and three standby databases. I followed the manual steps to set up the Data Guard Log Transport between the virtual primary database vP and its virtual standby databases (vS1, vS2 and vS3).
At Delphix, it is our goal to provide Data As A Service. Once we link data into Delphix, the number of things we can do with it is amazing. In this case, we start with one continuously synchronized copy of the production database. From this one copy, you can create multiple virtual standby databases, and configure them into many different kinds of Data Guard configurations. All of that can be done in a matter of minutes and with a fraction of the storage required for physical databases.
Customers who have applications tied to a Data Guard configuration can derive additional benefits from this capability for their application project development. Using Delphix, it is quick and easy to virtualize Oracle databases. You can take it one step further to provision your virtual Data Guard configuration. Having a virtual Data Guard configuration with actual production data allows you to test metrics promised by Data Guard without affecting your running Data Guard configuration.