High Availability and Disaster Recovery Best Practices for Oracle Database@Azure
High Availability and Disaster Recovery Best Practices for Oracle Database@Azure
Article Overview
Resilience on Oracle Database@Azure is not a single feature you switch on — it is a set of layered defences, each protecting against a bigger blast radius than the last. Oracle RAC handles a node dying. Availability zones handle a datacenter dying. Cross-region Data Guard handles an entire region dying. And backups handle the case where the data itself is wrong. This guide walks each layer with the architecture, the trade-offs, and the configuration, then ties them together using Oracle's Maximum Availability Architecture (MAA) tiers — Silver, Gold, and Platinum — which Oracle and Microsoft have validated for this platform. Five multicloud diagrams show exactly how the pieces fit across Azure availability zones, Azure regions, and OCI. Throughout, the emphasis is on choosing the right tier for a real recovery objective rather than over-engineering by default.
1.Start With RTO and RPO
Before any architecture, two numbers. Everything else in this article is downstream of them, and getting them wrong — in either direction — is the most expensive mistake in the whole discipline.
| Metric | The question it answers | Drives |
|---|---|---|
| RTO Recovery Time Objective | How long can we be down before it hurts the business unacceptably? | How fast failover must be — automatic vs manual, standby vs restore |
| RPO Recovery Point Objective | How much data can we afford to lose, measured in time? | Replication mode — synchronous (zero loss) vs asynchronous (seconds/minutes) |
The trap is treating "zero and zero" as the obvious answer. Zero RPO demands synchronous replication, which demands low latency between sites, which constrains how far apart they can be — and that same short distance limits protection against a large regional disaster. Zero RTO demands automatic failover with all the complexity that entails. Both cost real money and real engineering. The right numbers come from the business, tier by tier, not from an instinct to maximise.
A payments ledger and a reporting mart do not deserve the same resilience. Set RTO and RPO per workload, then buy exactly the architecture each one needs — no more.
A useful framing
RPO is a distance-and-money problem: the closer to zero, the more synchronous and the more expensive. RTO is an automation problem: the closer to zero, the more the failover has to happen without a human in the loop. Map each workload onto that grid before you open an architecture diagram.
2.The Layers of Resilience
Resilience is best understood as concentric rings, each defending against a failure the inner ring cannot. Understanding which ring catches which failure is what stops you from buying cross-region DR to solve a problem that RAC already handles — or, worse, assuming RAC protects you from a regional outage when it does nothing of the kind.
| Failure | Caught by | Not caught by |
|---|---|---|
| One database node crashes | Oracle RAC | — |
| A datacenter / availability zone goes dark | Cross-zone Data Guard | RAC alone (it lives in one site) |
| An entire Azure region fails | Cross-region Data Guard | RAC, zones |
| Data is deleted or logically corrupted | Backups (and flashback) | RAC, Data Guard — they faithfully replicate the corruption |
| The Azure control plane has an issue | An OCI-hosted standby | Anything living only in Azure |
⚠️ The two errors this table prevents
RAC is high availability, not disaster recovery. It keeps the database serving when a node dies, but every node is in the same place — a site or regional failure takes all of them. And Data Guard is not a backup. It replicates faithfully, which means it replicates a DELETE or a corruption just as faithfully. You need backups for the class of failure where the data itself is the problem. Confusing either of these is how "fully redundant" systems still lose data.
3.The MAA Tiers
Oracle's Maximum Availability Architecture packages these layers into named tiers, and Oracle's MAA engineering team has validated the Silver and Gold tiers for Exadata Database Service running on Oracle Database@Azure. Thinking in tiers is useful because it maps a coherent bundle of technology to a coherent level of protection, so you can point at a tier rather than assembling features one at a time.
SILVER
High availability within a single site. Oracle RAC on Exadata provides protection against instance and hardware failures, with rolling maintenance. This is the default posture of the platform — but on its own it has zero fault tolerance against a site or regional outage.
GOLD
Adds disaster recovery and data protection using Data Guard, with primary and standby databases configured across different availability zones and/or regions. This is the tier for anything that must survive the loss of a datacenter or a region.
PLATINUM
The most demanding tier, layering technologies like Application Continuity, Global Data Services, and edge protections on top of Gold so that even planned and unplanned outages are masked from end users. Reserved for systems where any visible interruption is unacceptable.
How to use the tiers
Do not start by picking a tier — start with the RTO and RPO from section 1, and let them select the tier. Most workloads land on Silver (HA is enough) or Gold (they need real DR). Platinum is a deliberate choice for a small number of systems where masking every outage from the user justifies the added complexity and cost.
4.Oracle RAC — Surviving a Node SILVER
Real Application Clusters is the innermost ring and the reason this platform starts life more available than most. Multiple database instances run on separate Exadata compute nodes, all opening the same database on shared storage. If a node fails, the others are already serving — there is no promotion step because nothing was standing by.
On Oracle Database@Azure this is the out-of-the-box behavior of an Exadata VM cluster: provision two or more nodes and RAC is doing its job. What you configure is how the application takes advantage of it.
4.1 Services and connection routing
The right pattern is to connect through a database service and the SCAN listener, never to a specific node. That way the cluster decides which instance serves each session, and a node loss is transparent to new connections.
# Create an application service that runs on both instances,
# so sessions spread across the cluster and survive a node loss
srvctl add service -db ERPPROD -service ERP_APP \
-preferred ERPPROD1,ERPPROD2 \
-tafpolicy BASIC \
-failovertype TRANSACTION \
-failovermethod BASIC \
-commit_outcome TRUE \
-notification TRUE
srvctl start service -db ERPPROD -service ERP_APP
srvctl status service -db ERPPROD -service ERP_APP4.2 Application Continuity — hiding the failure
RAC keeps the database up, but a session that was mid-transaction on the failed node still sees an error unless you configure Application Continuity. With it, the in-flight work is replayed on a surviving instance and the application never sees the interruption. This is the single most valuable RAC feature for user-facing systems, and it is what the Platinum tier leans on.
-- Enable the service attributes that make replay possible
BEGIN
DBMS_SERVICE.MODIFY_SERVICE(
service_name => 'ERP_APP',
failover_type => 'TRANSACTION', -- replay in-flight transactions
failover_restore => 'AUTO',
commit_outcome => TRUE, -- know for certain if a commit succeeded
replay_initiation_timeout => 1800,
failover_delay => 3,
failover_retries => 30);
END;
/
-- On the client side, use a recent JDBC/OCI driver and a connection
-- pool that supports the replay (UCP, or the driver's built-in pool).🔧 The best-practice connect string
Point applications at the service name through SCAN, enable Fast Application Notification (-notification TRUE) so the pool learns about node events instantly, and drain sessions gracefully during planned maintenance. Done well, rolling patching and a node failure look the same to the application: nothing.
RAC gives you the availability. Services, SCAN, and Application Continuity are what turn that availability into an experience the user never notices.
5.Availability Zones — Surviving a Datacenter GOLD
RAC protects against a node. It does nothing about the building that node sits in. Azure availability zones are physically separate datacenters within one region, and the Gold tier uses them to protect against a whole zone going dark — by placing a Data Guard standby in a different zone from the primary.
This is the recommended architecture for organizations that need near-zero RPO with redundancy across datacenters while keeping all data inside a single region — the common shape for data-residency-bound workloads.
The MAA guidance for the application tier matters as much as the database design: place application VMs in the same zone as the database they talk to for the lowest latency, using a direct path rather than routing through network virtual appliances or firewalls — and spread application VMs across multiple zones so the app tier is as resilient as the data tier.
6.Active Data Guard — the DR Engine GOLD
Data Guard is the technology under every Gold and Platinum architecture. It maintains a standby database as an exact physical replica of the primary by shipping and applying redo. Active Data Guard adds the ability to open that standby read-only while it applies redo — so the DR copy is not idle capacity but a live reporting and offload target, plus it brings automatic block-corruption repair.
6.1 Transport modes decide your RPO
| Protection mode | Transport | RPO | Distance tolerance |
|---|---|---|---|
| Maximum Protection | SYNC, commit blocks until standby acknowledges | Zero | Short — latency-sensitive |
| Maximum Availability | SYNC, but never stalls the primary if the standby is unreachable | Zero in normal operation | Short to moderate |
| Maximum Performance | ASYNC, primary never waits | Seconds to minutes | Long — cross-region friendly |
The choice is a direct trade: SYNC buys zero data loss but needs the standby close (same region, adjacent zones); ASYNC tolerates the latency of a distant region but accepts a small RPO. This single decision shapes every architecture that follows.
6.2 Configuring the standby with the broker
Use the Data Guard broker — it manages roles, transport, and failover as one configuration rather than a scatter of init parameters, and it is what enables fast, scripted, or automatic failover.
dgmgrl sys/****@ERPPROD
-- Create the broker configuration and add the standby
CREATE CONFIGURATION erp_dg AS
PRIMARY DATABASE IS ERPPROD
CONNECT IDENTIFIER IS ERPPROD;
ADD DATABASE ERPPROD_STBY AS
CONNECT IDENTIFIER IS ERPPROD_STBY;
-- Zero-data-loss within a region: synchronous, never stall the primary
EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
EDIT DATABASE ERPPROD SET PROPERTY LogXptMode='SYNC';
EDIT DATABASE ERPPROD_STBY SET PROPERTY LogXptMode='SYNC';
ENABLE CONFIGURATION;
SHOW CONFIGURATION VERBOSE;6.3 Fast-start failover — automatic promotion
For a low RTO you want the standby to promote itself without waiting for a human. Fast-Start Failover (FSFO), driven by an observer process, does exactly that when it detects the primary is gone.
-- Bound the data loss you will tolerate on an automatic failover
EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 30;
EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit = 0; -- 0 = zero-loss
EDIT DATABASE ERPPROD SET PROPERTY FastStartFailoverTarget='ERPPROD_STBY';
EDIT DATABASE ERPPROD_STBY SET PROPERTY FastStartFailoverTarget='ERPPROD';
ENABLE FAST_START FAILOVER;
-- Start an observer (ideally in a third location) to arbitrate
START OBSERVER;
SHOW FAST_START FAILOVER;Put the observer somewhere independent
The observer decides when to fail over, so it must not share a failure domain with the primary. Running it in a third availability zone — or in OCI — prevents the split-brain scenario where a network partition makes the primary and observer both think the other is dead. This detail is what separates a DR design that works in a drill from one that fails in a real outage.
6.4 Manual switchover and failover
-- Planned, reversible role swap (maintenance, region migration, DR test)
SWITCHOVER TO ERPPROD_STBY;
-- Unplanned promotion when the primary is truly gone
FAILOVER TO ERPPROD_STBY;
-- After the old primary returns, reinstate it as the new standby
REINSTATE DATABASE ERPPROD;
VALIDATE DATABASE ERPPROD_STBY; -- confirms it is ready to take the primary role7.Cross-Region DR GOLD
Cross-zone protection survives a datacenter. It does not survive the loss of an entire region — a rare but real event, and one that compliance regimes increasingly require you to plan for. The answer is a Data Guard standby in a second Azure region, replicating asynchronously because the distance rules out synchronous transport.
This is also where the application tier has to be part of the DR design, not an afterthought. A database that fails over to another region is useless if the application cannot follow it.
7.1 The details that make cross-region DR actually work
- TDE keys must travel. A standby cannot open an encrypted database without the keys. The pattern is to hold TDE master keys in OCI Vault and replicate them between the OCI regions backing each Azure region — so the standby has what it needs, independent of the failed side.
- Backups belong in both regions. Automatic backups to OCI Object Storage or Autonomous Recovery Service should exist for both primary and standby, so you can restore locally after a regional failover instead of reaching back into a dead region.
- The application must be pre-staged. Container images replicated to the standby region's registry, the app pre-deployed and scaled down, and a global traffic manager health-routing users. Failing the database over in minutes is pointless if standing up the app takes hours.
- Network path. Connectivity between primary and standby can run over Azure networking or OCI networking; by default the primary route is through Azure. Plan the aggregate redo throughput the link must sustain at peak.
8.Zero-Data-Loss With an OCI Standby PLATINUM
Here is the option unique to this multicloud platform, and it is genuinely clever. Because OCI and Azure datacenters are physically co-located in the same region, you can place the primary on Oracle Database@Azure and an Active Data Guard standby on OCI within the same region — close enough for synchronous replication and therefore zero data loss, while protecting against a complete outage on the Azure side.
The networking is a local peering connection between the Azure-side VCN and the OCI-side VCN, joined through their local peering gateways. Because the two sit in the same physical region, redo transport is fast enough for synchronous mode — giving a zero-data-loss configuration that spans two clouds while still meeting single-region data-residency requirements. It is the clearest example of the platform's multicloud nature turning into a concrete resilience advantage.
🔧 When this architecture earns its place
Choose an OCI standby when you need zero data loss and protection against an Azure-side failure and the data must stay in one region. If cross-region protection matters more than a zero RPO, an asynchronous standby in a second Azure region is the better fit. Many demanding estates run both: a synchronous OCI standby in-region for zero-loss failover, and an asynchronous standby in a distant region for true geographic DR.
9.Backup and Recovery Strategy
Backups protect against the one failure no amount of replication can catch: the data itself being wrong. A dropped table, a bad batch job, a logical corruption — Data Guard replicates every one of them to the standby, faithfully and instantly. Only a backup, or a point-in-time flashback, gets you a version of the data from before the mistake.
9.1 The backup options on this platform
| Option | What it is | Best for |
|---|---|---|
| Autonomous Recovery Service | Oracle's managed, incremental-forever backup and recovery service, available in Azure or OCI | The default for most workloads — validated, automated, minimal-loss recovery |
| OCI Object Storage | Automatic backups written to durable object storage | A straightforward, cost-effective managed backup target |
| RMAN (manual) | Traditional scripted backups you control end to end | Bespoke retention, extra copies, or integration with existing tooling |
| Flashback | Fast rewind of the database (or a table) to a past point | Recovering from a recent logical error in seconds, no restore needed |
9.2 Flashback — the fastest recovery you are not using
For a mistaken DELETE or a botched deployment, restoring from backup is the slow answer. Flashback rewinds in seconds. Configure it ahead of time so it is available when you need it.
-- Enable Flashback Database and set how far back you can rewind
ALTER SYSTEM SET db_flashback_retention_target = 2880; -- minutes = 48 hours
ALTER DATABASE FLASHBACK ON;
-- Guard a risky change with a named restore point first
CREATE RESTORE POINT before_release_2026_07 GUARANTEE FLASHBACK DATABASE;
-- ... if the release goes wrong, rewind the whole database to that point:
-- SHUTDOWN; STARTUP MOUNT;
-- FLASHBACK DATABASE TO RESTORE POINT before_release_2026_07;
-- ALTER DATABASE OPEN RESETLOGS;
-- Or recover a single dropped table without touching anything else
FLASHBACK TABLE sales.orders TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE);9.3 A sound RMAN baseline
Even with managed backup services, knowing the RMAN policy that underpins them is worth having.
-- Retention, block-change tracking for fast incrementals, autobackup
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEVICE TYPE DISK PARALLELISM 8;
-- Weekly level-0, daily level-1 incremental, frequent archivelog backups
BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG; -- weekly
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; -- daily
BACKUP ARCHIVELOG ALL DELETE INPUT; -- through the day
-- Prove the backup is restorable WITHOUT actually restoring
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;⚠️ A backup you have never restored is a hope, not a backup
The most common DR failure is discovering, during a real incident, that the backups do not restore — a missing key, a gap in the archivelogs, an untested retention policy. Schedule a genuine restore to a scratch environment on a regular cadence. RESTORE ... VALIDATE is a good cheap check, but nothing substitutes for occasionally building a database from your backups end to end.
10.Application-Tier Resilience
A perfectly resilient database behind a fragile application tier is a fragile system. DR is only real when the whole path from user to data survives the failure — and the application side is where otherwise-solid designs quietly fall down.
| Concern | Best practice |
|---|---|
| Latency to the database | Place app VMs in the same availability zone as the primary, with a direct path — no network virtual appliances or firewalls in the hot path |
| App-tier HA | Spread application VMs or AKS nodes across multiple zones so a zone loss does not take the app with the database |
| Connection resilience | Connect via the service name through SCAN; enable Fast Application Notification and connection-pool draining so node and role changes are transparent |
| Region failover | Pre-deploy the app in the standby region, replicate container images to that region's registry, and health-route with a global traffic manager |
| Transparent outage masking | Application Continuity replays in-flight transactions so users do not see brief database interruptions during failover or maintenance |
| Config and secrets | Ensure TNS entries, wallets, and connection secrets for the standby exist in the standby region ahead of time, not created during the incident |
Test the failover by pulling the plug on the primary, not by reading the runbook. The gap between "we have DR" and "our DR works" is almost always in the application tier.
11.Testing Your DR — or It Doesn't Exist
An untested DR plan is a document, not a capability. The whole point of Data Guard's switchover is that it is a clean, reversible role swap — which means you can rehearse a real failover on a schedule, prove your RTO and RPO, and switch back, all without data loss.
11.1 A DR drill that actually proves something
- Snapshot the starting state. Record roles, apply lag, and open modes on both databases.
- Switch over. Use
SWITCHOVER TO— the planned, reversible path — and time it against your RTO. - Fail the application over too. Repoint the app tier, or trigger the traffic-manager failover, and run the smoke tests. This is the step most drills skip and most real incidents fail on.
- Run the business validation. Not just "the database is open" — run the transactions the business actually depends on.
- Measure and record. Actual RTO, actual RPO, anything that surprised you. Feed it back into the runbook.
- Switch back. Return to the original primary and confirm the environment is exactly as it started.
-- 1. Confirm the standby is healthy and caught up before you start
SHOW CONFIGURATION VERBOSE;
VALIDATE DATABASE ERPPROD_STBY;
-- 2. Planned, reversible switchover (time this against your RTO)
SWITCHOVER TO ERPPROD_STBY;
-- 3. ... repoint the app, run smoke + business validation ...
-- 4. Switch back to the original primary
SWITCHOVER TO ERPPROD;
-- 5. Confirm you are exactly where you started
SHOW CONFIGURATION; -- roles restored, configuration SUCCESSCadence beats perfection
A modest DR test run every quarter is worth far more than an elaborate one planned and never executed. Regular, boring drills catch the small drift — an expired key, a missing TNS entry, a firewall change — that turns a real failover into an outage. Put it in the calendar and treat a skipped drill as an incident in its own right.
12.Choosing a Tier
Pull it all together: match the workload's real recovery objectives to the smallest tier that meets them.
| ier | Protects against | Technology | Typical RTO / RPO |
|---|---|---|---|
| SILVER | Node and hardware failure within a site | RAC on Exadata, rolling maintenance | Seconds RTO / zero for a node loss; no site protection |
| GOLD | Zone or region loss | + Data Guard across zones (SYNC) or regions (ASYNC) | Minutes RTO / zero to seconds RPO |
| PLATINUM | Any visible interruption, planned or unplanned | + Application Continuity, Global Data Services, edge protections | Near-zero RTO, outages masked from users |
13.Frequently Asked Questions
Is RAC enough for disaster recovery?
No. RAC is high availability — it survives a node failure, but all its nodes live in one site, so a datacenter or regional outage takes the whole cluster. For DR you need Data Guard across zones or regions. RAC and Data Guard solve different problems and you generally want both.
Can I get zero data loss across two regions?
Not practically. Zero RPO needs synchronous replication, and the latency between distant regions makes SYNC impractical. For zero data loss you keep the standby close — a different zone in the same region, or an OCI standby co-located in the same region. Cross-region DR uses asynchronous transport and accepts a small RPO.
What is special about the OCI standby option?
Because OCI and Azure datacenters are co-located in the same region, a standby on OCI is close enough for synchronous replication — giving zero data loss while protecting against an Azure-side outage, all within one region. It is a resilience option that only exists because of the multicloud co-location.
Do I still need backups if I have Data Guard?
Absolutely. Data Guard replicates everything faithfully, including a dropped table or a logical corruption. Only backups and flashback recover the data as it was before the mistake. They protect against a different class of failure entirely.
Where should the Data Guard observer run?
Somewhere that shares no failure domain with the primary — a third availability zone, or OCI. If the observer can fail together with the primary, automatic failover cannot be trusted, and you risk split-brain during a network partition.
How do I avoid the standby being wasted capacity?
Use Active Data Guard: the standby stays open read-only while applying redo, so it serves reporting and read-offload workloads instead of sitting idle. It also adds automatic block-corruption repair between primary and standby.
How often should we test failover?
At least quarterly, and always end to end — database and application together, with real business validation. Because switchover is reversible, a proper drill costs you a maintenance window, not data. A DR plan you have never executed should be assumed not to work.
Which tier do most workloads need?
Silver or Gold. Silver (RAC HA) covers anything that only needs to survive hardware failure; Gold (Data Guard DR) covers anything that must survive a site or region. Platinum is a deliberate choice for the few systems where masking every outage from users justifies the extra complexity.
14.Key Takeaways
The short version
• Start with RTO and RPO. Every architecture choice is downstream of those two numbers — set them per workload and resist the reflex to maximize.
• Think in rings. RAC survives a node, zones survive a datacenter, cross-region Data Guard survives a region, backups survive bad data. No ring replaces the one outside it.
• RAC is HA, Data Guard is DR, backups are neither's substitute. Confusing these is how "redundant" systems still lose data.
• The OCI standby is the multicloud superpower — synchronous, zero-data-loss failover across two clouds in one region, unavailable anywhere else.
• Untested DR is not DR. Drill end to end on a schedule, application included, and measure your real RTO and RPO.
• Map to MAA tiers — Silver for HA, Gold for DR, Platinum to mask every outage — and buy the smallest tier the business actually requires.
Resilience on Oracle Database@Azure is not a product you buy; it is a set of decisions you make, each one trading cost and complexity for protection against a larger failure. The platform gives you an unusually complete toolbox — RAC for local HA, Active Data Guard across zones and regions, a genuinely novel synchronous OCI standby, and managed backup and recovery — validated by Oracle against the MAA tiers. The engineering discipline is the same it has always been: know your recovery objectives, layer the defences that meet them, and prove the whole thing works before you need it to.
Do that, and the question stops being "will we survive an outage?" and becomes "which tier did we decide this workload deserves?" — which is exactly the question you want to be answering.
Disclaimer: MAA tier definitions, validated architectures, and platform capabilities reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current details and supported configurations against Oracle and Microsoft sources before designing a production topology. All commands and configuration are illustrative, use placeholder values, and must be validated against your own versions and current documentation before use. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments