BCP/Standby/DR Testing with Delphix Standby dSources

  • 0
  • 2
  • Article
  • Updated 3 years ago
  • (Edited)
About this Document

This document explains a process for performing Business Continuity Tests (BCP Tests, Failover Tests, DR Tests) when using a Physical Standby database as a Delphix dSource. This document is specific to Oracle databases, and to Physical Standby Databases.


Background

  Physical Standby as a dSource

The most common Delphix topology uses Production data as the dSource, from which all VDBs (clones) are initially created.  To minimize the configuration changes needed on production systems, a physical standby can be used.

For more information on linking Delphix to a Physical Standby, see http://docs.delphix.com/display/DOCS/Linking+Oracle+Physical+Standby+Databases.


  BCP Testing

Best practices demand regular testing of Business Continuity Processes.  But the testing process typically involves resetting the logs on the standby system. What is the effect of the resetlogs operation on a Delphix dSource? What is the best procedure to use when performing a failover test, when the Physical Standby is used as the dSource?


Effect of Resetlogs on a Delphix dSource

Prior to Delphix 4.2, a resetlogs operation was very disruptive, and required creating a new dSource.

With Delphix 4.2 and higher, the effect of the resetlogs operation on a Delphix dSource is mitigated. As described here, https://docs.delphix.com/display/DOCS/Oracle+Source+Continuity, a simple operation preserves the dSource and starts a new Timeflow.  Storage savings are preserved.

While the old timeflow can still be accessed, and is retained according to the normal retention policies, it is not visible in the GUI.

Don’t worry!  Although the GUI only shows the current timeflow, the older timeflow can still function as an archive, and can be used to create VDBs.  But you must use the CLI (Command Line Interface) as described in the link above.  

In addition, the first Snapsync operation can take many hours/days to complete, as all database blocks are read, transmitted to the Delphix Engine over the network, and compared to existing blocks in order to determine the blocks which have actually changed.  

A Better Solution

Reduced functionality in the GUI, and the need to use CLI syntax, can be a significant hurdle for some customers.  In addition, the long operation can create unacceptable delays for developers who need fresh data.

Luckily, there is a simple way to completely preserve your existing dSource and timeflow.  You’ll be able to access all your old snapshots from the GUI, with no gaps or long delays.

Simply disable the dSource prior to the test, and use the Oracle Flashback Database feature to undo the resetlogs operation when your testing is complete.  Enable the dSource, and Delphix will continue as if nothing happened!  Since the flashback also returns the standby to the prior resetlogs setting, Delphix will not be aware that a resetlogs occurred.

NB:  It is not necessary to detach/attach the dSource.  The simpler disable/enable commands are sufficient.


Full Recipe

The process is as simple as it sounds, but here’s a working recipe:

  1. disable the dSource (Delphix GUI/CLI)

  2. convert physical standby to snapshot standby (Oracle commands)

  3. perform your regular business continuity testing

  4. flashback snapshot standby (Oracle commands)

  5. convert snapshot standby to physical (Oracle commands)

  6. enable the dSource (Delphix GUI/CLI)


Conclusion

By integrating this simple technique into your BCP test, you can make sure that your Delphix landscape is unaffected.  Happy virtualizing!

Photo of Ranzo Taylor

Ranzo Taylor, Employee

  • 1,604 Points 1k badge 2x thumb

Posted 3 years ago

  • 0
  • 2

Be the first to post a reply!