High Availability for Oracle Database on OCI

For most enterprises the Oracle Database is the single most important thing running, because it holds the state that everything else depends on. If the database is available and intact, almost everything else can be rebuilt around it, and if it is not, nothing else matters. High availability for Oracle Database on OCI is therefore the centre of gravity of the whole resilience design. This article explains the techniques OCI offers to keep an Oracle Database running through the everyday failures that happen all the time, how they layer together, and how to choose the right level of protection for a given database without over engineering it.

High availability versus disaster recovery for the database

It helps to keep the two layers distinct even when talking only about the database. High availability is about surviving the frequent, local failures, a node reboot, a hardware fault, a process crash, with little or no interruption and usually automatically. Disaster recovery is about surviving the rare, large failures, the loss of a site or a region, through a deliberate failover to somewhere else. The database needs both, and the techniques differ. High availability uses clustering and redundancy within a region, while disaster recovery uses Data Guard standbys across availability domains or regions. This article focuses on the high availability layer, with the wider picture in the disaster recovery pillar.

Real Application Clusters

The cornerstone of Oracle Database high availability is Real Application Clusters, where multiple database instances on different servers access a single shared database at once. If one node fails, the others keep serving, and the database remains available through the failure with no restore and minimal interruption. On OCI, clustering is available on the database services that support it, and it protects against the most common cause of database downtime, the loss of a single server. Clustering also allows rolling maintenance, where nodes are patched one at a time while the database stays up, removing a major source of planned downtime as well as unplanned.

Spreading across the resilience hierarchy

Database high availability on OCI is most effective when it is mapped deliberately onto the platform's fault isolation layers. The cluster nodes should be distributed across fault domains so a hardware or maintenance event affecting one does not take down the others, and for higher availability across availability domains so the loss of a whole data centre is survivable. This is the same hierarchy that governs all OCI resilience, applied specifically to the database tier.

The table shows how the techniques layer: clustering handles node loss with near zero interruption, distribution across availability domains handles data centre loss, and Data Guard handles regional loss, as covered in cross region DR on OCI. A serious database design uses all of these layers, each matched to a scale of failure.

High availability across the database services

How much of this you configure yourself depends on which OCI database service you choose. On Base Database you assemble and manage the high availability features directly. On Exadata Database Service the platform provides clustering and redundancy as part of a highly engineered system designed for availability. On Autonomous Database, high availability is largely built in and managed for you, with the platform handling node redundancy and patching automatically. The principle is constant across all of them, redundancy so that no single failure takes the database down, but the operational effort decreases as you move toward the more managed services. Choosing the right service is itself part of designing for availability.

A database HA framework

Matching protection to the database

Not every database needs the full stack of protections, and applying it everywhere wastes money. A mission critical transactional database justifies clustering, multi availability domain distribution, and a Data Guard standby. A development database may need none of it. A reporting database may be adequately protected by backups and a relaxed recovery time. The discipline is to match the protection to the value and criticality of each database rather than applying a single standard everywhere, which is the same cost to value matching that runs through the entire disaster recovery and HA approach. Over protecting a trivial database is as much a design failure as under protecting a critical one.

The backup safety net

High availability and Data Guard protect against losing the infrastructure, but they do not protect against the data itself going wrong, because a corruption or accidental deletion replicates to every clustered node and standby. That is why even the most highly available database still needs backups, the only protection against logical failure, covered in backup strategies for OCI workloads. A database with perfect availability and no usable backup is one bad transaction away from disaster, so the two layers are complementary rather than alternatives.

Bringing it together

High availability for Oracle Database on OCI is built from clustering for node failures, distribution across the fault isolation hierarchy for site failures, Data Guard for regional protection, and backups for logical failures, each layer matched to a scale of failure. Set the target from criticality, layer the protections deliberately, choose the service whose managed level fits your team, and test the failover. Match the protection to the value of each database and you get reliability without waste. Continue with Data Guard on OCI explained, cross region DR on OCI, and backup strategies for OCI workloads, and return to the disaster recovery pillar.