Oracle Database - Resilient Architectures

Though there are other expensive architectures that can be designed for Oracle databases to achieve site failure scenarios, the architecture described above is the cheapest and most effective resilient architecture for an Oracle database.

Instance Resiliency

Oracle Real Application Clusters (RAC) provides high availability where even if one instance/server crashes, still other instance can accept the? connections from the application and serve the business. When planning for Oracle RAC capacity, it is important to ensure that the entire load can be accepted even if one node fails. Many mission-critical applications tend to be very demanding and are often load-balanced both at the front end (application servers) and back end (database servers).

Storage Resiliency

An ASM failure group is a protection mechanism against disk problems in ASM disk groups. Idea is to carve out the ASM disks (equal capacity) from two different Storage frames and create ASM fail groups with Normal Redundancy. Advantage is that, even if one of the storage frame is unavailable, still the disk groups will be functional. Also, ASM Fail group ensures that data and its redundant copy do not both reside on disks that are likely to fail together.

Disadvantage: After a disk group is created we cannot alter the redundancy level of the ASM Disk Group.

Interconnect Resiliency

The private interconnect is a critical component of Oracle RAC, and it is used for communication between the nodes in the cluster. Highly Available IP (HAIP) is a feature introduced by Oracle to eliminate a single point of failure in the Cluster Interconnect can be leveraged.

Handling Site Failure

In the event of site failure, you can use Oracle Dataguard to failover to the DR site (DG Broker makes it faster). A failover may or may not result in data loss depending on the protection mode in effect at the time of the failover. The default protection mode is “Maximum Performance” which is an asynchronous replication and data loss is inevitable. Again, the RPO should be considered during the design phase to define the protection modes. If your former primary database was configured with Flashback Database with (n) hours of retention,? you can easily reinstate the failed primary database as a standby database of the new primary database, rather than re-creation of the standby database. The failed primary database will be reinstated as a standby type that matches the old standby database.