Non-disruptive DR Drills for Oracle Databases Using Pure Storage ActiveDR — Part 3 of 4

This is part three of a four-part series on using Everpure ActiveDR to protect, test, and fail over Oracle databases without taking production offline.

In part 2, we completed the DR database configuration using the replicated volumes protected in part 1. Part 3 shows how to use simple scripting to run on-demand DR drills without disrupting the production site.

Zero-risk DR testing you can run any time — no more weekend office hours — and as often as needed is a meaningful shift for most teams. How many organizations have released a new application into production without confirming its DR process actually works? Full-scale legacy failovers are too disruptive to run for every release, so DR processes often go untested until the next scheduled drill, which could be six months away or more. Non-disruptive DR drills close that gap and remove the uncertainty around what really happens in a disaster.

With ActiveDR and the database configuration from parts 1 and 2 in place, on-demand non-disruptive DR drills come down to five steps:

  • Promote the Oracle-DR pod
  • Start the DR database services and applications
  • Complete any DR verification tests
  • Stop the DR applications and database services
  • Demote the Oracle-DR pod

This can be done with a few clicks in the DR Everpure FlashArray console and by starting the DR database manually at the command line. In practice, most teams will want this automated. Sample shell scripts that handle the process are available in Everpure’s GitHub examples repository at:

https://github.com/PureStorage-OpenConnect/oracle-scripts

Important: all scripts are provided as-is without warranty or formal support. Review, adapt, and test in non-production environments and validate against internal standards before production use.

The scripts and what they do:

  • dr_inserts.bash: repeatedly inserts and reads back rows on the DR database. This reports errors while the Oracle-DR pod is demoted, since the database is unavailable in that state.
  • dr_drill_start.bash: starts a DR drill by promoting the Oracle-DR pod, mounting the ASM diskgroups, and starting the DR database.
  • dr_drill_end.bash: ends the DR drill by stopping the DR database, dismounting the ASM diskgroups, and demoting the Oracle-DR pod.

This process is easier to see in action than to describe in screenshots — see the short demo video below.

The video walks through configuring ActiveDR for an Oracle database, then running a non-disruptive DR drill end to end.

The three pod states

The Oracle-DR pod moves through three states during a drill, each triggered by a single click or CLI command:

  • Before the drill — demoted: the DR pod receives updates from the source pod over the replica link, and its volumes are read-only.
  • During the drill — promoted: replication pauses and queues, and the pod’s volumes become read/write, allowing the database to open.
  • After the drill — demoted: the volumes return to read-only and roll back to their pre-drill state using a hidden snapshot taken at promotion time. The queued replication writes from the source are then applied, resynchronizing the DR volumes with the latest production data.

A FlashArray system can host multiple pods for different purposes, so this isn’t an all-or-nothing approach. You might run an independent pod per database, group several databases into one pod, or keep SQL databases in one pod and Oracle databases in another. Some databases might not run in a pod at all — for example, systems replicated by snapshot for downstream reporting that need to stay available continuously. How you configure this is entirely up to how you want to operate, and ActiveDR is included with every Everpure FlashArray at no additional cost.

With this process in place, DR drills stop being a disruptive, once-or-twice-a-year event and become a routine, low-risk part of releasing to production. But what happens with a real disaster, not just a test, when a full failover is required? We’ll cover that in the final post of this series, part 4.