3.3 DR Drills, Plan Customization & Operational Readiness
Key Takeaways
A Start Drill execution creates a replica of the application stack in the standby DR protection group, and a Stop Drill execution terminates that replica.
For Base Database and Exadata Database members, Start Drill converts the standby database to a snapshot standby, and Stop Drill converts it back to a physical standby.
For Autonomous AI Database Serverless members, a drill uses either a snapshot standby or a clone or refreshable clone, depending on the member setting.
User-defined steps can run a script from Object Storage, run a local script on an instance through the Oracle Cloud Agent, or invoke an OCI Function.
While the protection groups are in the drill-in-progress state, only a Stop Drill plan can be executed.
Why Drills Matter
Regulators and auditors increasingly expect evidence that disaster recovery works, not just a written plan. Traditional DR tests often required breaking replication or scheduling downtime. Full Stack DR provides two plan types for testing: Start Drill and Stop Drill. A drill brings up a replica of the application in the standby region while production keeps running and replication continues.
What a Drill Does to Each Member Type
Full Stack DR generates built-in drill steps from the members of the protection groups:
| Member type | Start Drill | Stop Drill |
|---|---|---|
| Moving compute instance | Launches the instance in the standby region | Stops and terminates the drill instance and removes it from the DRPG |
| Non-moving compute instance | Starts the standby instance and attaches block volumes if configured | Detaches the block volumes and stops the instance |
| Volume group | Restores the volume group in the standby region from its replica or backup | Terminates the restored volume group |
| Base DB / Exadata database | Converts the standby to a snapshot standby | Converts it back to a physical standby |
| Autonomous Container Database | Converts the standby to a snapshot standby | Converts it back to a physical standby |
| Autonomous AI Database Serverless | Converts the cross-region standby to a snapshot standby, or creates a clone or refreshable clone | Converts back to physical standby, or deletes the clone |
| MySQL HeatWave DB system | Built-in Start Drill steps | Built-in Stop Drill steps |
A snapshot standby is a standby database opened read-write for testing. It keeps receiving redo from the primary but does not apply it until it is converted back, at which point the test changes are discarded and the standby catches up. Production replication is therefore never broken by the drill.
While the protection groups show a drill in progress state, the only plan you can execute is Stop Drill. You cannot start a switchover or failover until the drill is cleaned up, so always finish drills promptly.
Keeping the Drill Isolated
The biggest risk in a drill is a test copy that talks to production. Practical controls include:
- Separate drill networking. When you add a moving instance, you define VNIC mappings to destination subnets. Point drill traffic at subnets whose route tables and security rules do not reach production systems or on-premises networks.
- Separate DNS and connection strings. Make sure drill instances resolve test database endpoints, not the production primary.
- No production traffic. Do not add drill instances to production load balancer backend sets. Test through a private endpoint or a separate listener.
- Least privilege. The resource principal that Full Stack DR uses should only reach the compartments involved in the plan.
Extending Plans with User-Defined Steps
Infrastructure recovery is only half the job. Applications often need startup ordering, configuration changes, and smoke tests. Full Stack DR supports three kinds of user-defined steps:
| Step type | How it runs | Typical use |
|---|---|---|
| Run Object Storage script | Downloads a script from a bucket and runs it on an instance | Centrally managed scripts reused by many plans |
| Run local script | Runs a script already on the instance through the Oracle Cloud Agent Run Command plugin | Mount file systems, update configuration, start services |
| Invoke Function | Calls an OCI Function | Control-plane tasks such as updating a DNS steering policy or calling an ITSM webhook |
Run Command works through the Oracle Cloud Agent's outbound connection, so you do not need to open inbound SSH or create a bastion session for drill instances. The instance must have the Compute Instance Run Command plugin enabled, and Full Stack DR's dynamic group needs permissions such as manage instance-agent-command-family. Functions invoked from a plan need read fn-app, read fn-function, and use fn-invocation permissions for the Full Stack DR dynamic group, and a synchronous function call can run for at most 300 seconds.
You can also add a pause group, which stops the plan at a chosen point until an operator resumes it. This is useful when a manual verification, such as a business user checking a report, must happen before traffic is redirected.
Evidence for Auditors
A drill is only useful for compliance if you can show what happened:
- Plan execution history in the Console shows each group and step, its status, and its duration.
- Operation logs are written to the Object Storage log location configured for Full Stack DR, including output from user-defined scripts.
- OCI Audit records every Full Stack DR API call, such as creating plans and launching executions. Audit logs are retained for 365 days.
- Events from Full Stack DR resources can trigger notifications when an execution starts, fails, or completes.
Measure the elapsed time of each drill against your RTO target, and compare the database and storage recovery points against your RPO. Repeating the drill after every major architecture change keeps the plan aligned with reality.
Drill Checklist
- Run prechecks on the Start Drill plan.
- Execute Start Drill and confirm that every group succeeds.
- Test the application through isolated endpoints.
- Record timings and results.
- Execute Stop Drill to remove the replica and return databases to physical standby.
- Fix any failed steps and refresh the plans if members changed.
A compliance officer asks whether running a Full Stack DR drill will break replication of the Base Database Service primary to its Data Guard standby. How does the Start Drill plan treat the standby database?
It switches over Data Guard so the standby is the read-write primary during the test
It converts the standby to a snapshot standby, and Stop Drill converts it back
It deletes the Data Guard association and rebuilds it from a backup when the drill ends
It leaves the standby mounted read-only, so the drill cannot test database writes
During a DR drill, newly launched instances must mount a file system and start services in a specific order. The security team forbids opening inbound SSH or creating bastion sessions for the drill network. Which plan customization meets these requirements?
A user-defined step that runs a local script through the Oracle Cloud Agent Run Command plugin
A user-defined step that invokes a function to open SSH sessions to the instances through an internet gateway
A cloud-init script added to the primary instance's boot volume before replication starts
A Bastion managed SSH session step inserted into the DR plan after the launch group
A drill is still running when a real outage hits the primary region. The protection groups show a drill-in-progress state. What must happen before the team can run the Failover plan?
Nothing; a Failover plan can run at any time and cancels the drill automatically
The team must delete both DR protection groups and create new ones first
Run the Stop Drill plan first, because only Stop Drill can run during a drill
Refresh the Failover plan, which converts the drill resources into production
Sections you finish are checked off in the contents.