In my previous article I described some best practices in architecting database systems High Availability Levels (HA) 2 and 3 describing some technical solutions based on Data Guard, Standby database and Oracle Real Application Cluster (RAC). This time I’ll continue till Availability level 4 describing cluster database solutions based on Oracle Extended RAC and Oracle Maximum Availability Architecture (MAA) principles with combinations of Oracle RAC and Standby databases. I suggest reviewing a few of my previous articles on database High Availability including the Availability Continuum graph that illustrates and depicts the increases in availability that can be gained with the progression between levels of availability:
High Availability and SLA requirements for Oracle database
Oracle High Availability – ASM, Clusterware, Cold Failover
Oracle database High Availability – Data Guard, Standby, RAC
Availability Level 3b: Recovery via Redundant Components – Extended RAC
Oracle Database with Oracle RAC architecture is designed primarily as a scalability and availability solution that resides in a single data center. It is possible however, under certain circumstances, to build and deploy an Oracle RAC system where the nodes in the cluster are separated by up to 100 kilometers, to share the same RAC database with multiple RAC instances spread across two sites. This architecture is referred to as an Extended RAC or Metro cluster. We can consider this database architecture as an extension of Availability level 3.
The advantages of using Oracle RAC on extended clusters include: Read more »
In my previous article High Availability and SLA requirements for Oracle database we discussed that the successful High Availability (HA) begins with the understanding of Service Level Agreements (SLA) required by the business along with each of these dimensions. This guides important decisions on IT technology and determines the appropriate level of investment in HA architecture. Choosing the right technical solution for database system design from scratch is difficult. You can follow some best practices in building High Available Oracle database systems based on Availability Levels that match database industry standards. In this article I’ll share some best practices and my experience in architecting database systems for first 2,5 Availability Levels describing some technical solutions based on SAN, cluster, Clusterware, Oracle ASM, Cold Failover Cluster (CFC).
I’ll start with a graph below that illustrates Availability Continuum and depicts the increases in availability that can be gained with the progression between levels of availability. It is not based on empirical data, and the percentage values used are for illustrative purposes only, but being close (based on my experience) to real figures in common IT infrastructure for Oracle database environments though.
Another way to interpret the y-axis scale is as a measure of acceptable down time – the lower end of the axis represents a reasonable amount of down time as tolerable, whereas the upper end of the axis represents even the smallest amount of down time as being intolerable.