The Oracle High Availability Architecture with Oracle 12c RAC as the main pillar emerged as the foundation for the Application Resiliency.  Business continuity, high availability, scalability, flexibility and the agility combined with easy management are the key benefits of the Oracle 12c RAC.  When combined with the HA components like Flashback features, Flex ASM, Transaction Guard and the HA Backups, we can achieve Application High Availability (AHA) with Oracle 12c RAC.

What is Application High Availability anyway?  When the application is able to sustain from all types of disasters which include data center shutdown, data corruption, ASM challenges, Transaction incompleteness and backup issues the business can achieve the AHA.  The concept of AHA is very important for several businesses these days and the AHA can only be achieved with the cohesive existence of Oracle High Availability components.

The preferred approach for the Oracle 12c RAC implementation is starting with three nodes and making each node scalable vertically until each node reaches its maximum capacity.  If it is just a two node RAC, we cannot achieve true high-availability because if one node is down, all the load will be on the second node.  Beyond three nodes, we need to be prepared for more brown-out time due to cache fusion whenever one of the nodes is down.  In fact when the number of nodes keeps increasing, the brown-out time keeps increasing.  So we need to start with three node (ex. RHEL 6.0/Oracle 12c) configuration for the Prod and the Pre-Prod databases.  We want to maintain consistency at least between the Prod and Pre-Prod so that it is easier to simulate and test the upgrades/patches.  We need to have an equivalent three node RAC configuration on DR/Standby side.

We need to configure Flex ASM to increase the database instance availability so that the application resiliency can be improved and the overall Oracle ASM related resource consumption can be reduced.  We need to create separate services based on the application functionality- like one service for the OLTP application, the second service for the reporting application, the third service for the batch loads like ETL and the fourth service for the backups.  The idea behind separate services is the corresponding applications can be isolated to specific node or nodes which in turn gives flexibility.  For example, the OLTP service can be on all the three nodes whereas the backup service can be on just one node.

We need to implement all the Flashback features which together need decent size Undo, minimum Supplemental logging, and enough storage for the Flashback logs.  The Flashback features dramatically improve the application availability when there is a data corruption or when somebody drops an object.  We need to have the Flashback database turned on both on the primary and the standby side so that we can exercise Flashback database on standby side if somebody drops an object.  When the database is used by multiple applications we cannot Flashback the database on primary side when there is a data problem.  So whenever there is a data problem we need to  Flashback the database on the standby side which is really an active data guard (ADG).  Then the application users can compare the Flash-backed standby (ADG) database tables with the primary database tables and extract the data they need.  With this approach we can always rebuild the standby after the primary database is fixed with the right data.  Also if there is a block corruption on primary side, we can use block recovery option using the standby.

In addition we need to configure the Rman backups using dual copy approach keeping the application availability and resiliency requirement in view.  All the backups first go onto the disk and then they are backed up onto the tape.  Two consecutive level 0 backups always stay on the disk.  Since most of the data issues/corruptions are known within hours/days, we do not have to depend on tape system most of the times and we can restore just from the disk.  We also need to use Oracle 12c Transaction Guard feature to ensure that the application always gets expected result back from the database despite a failure on the database level or user induced mis-operation.  Now we want to come back to the AHA as all the pre-requisites (Oracle 12c RAC, Flashback features, Flex ASM, Transaction Guard and the HA Backups) required for the AHA are presented above.

Though we briefly defined the AHS above, we want to present how we can achieve that AHA with the core High Availability Oracle features.  When there is an identical RAC configuration in both the primary data center and the secondary or DR (Disaster Recovery) data center for the same database, the application can run either in the primary or secondary data center.  The corresponding identical layers like middleware and web should also be present in both the data centers of course.  The idea behind the AHA is keeping the application a few months in one data center and another few months in the other data center so that the business can run continuously without interruption even there is a major disaster like the data center outage for a pro-longer period.  To make the application switchover and switchback seem less we can come up with C-Names (Canonical Names) approach for the database layer (and other layers too) so that no application configuration needs to be changed during switchover/switchback.

In this technical paper we will present the details regarding the Application High Availability design and how the Oracle High Availability features will help in achieving such Application High Availability.

Eligible for Certificate: #IOUGeniusCert; #IOUGeniusHA

Info: www.collaborate.ioug.org/certificates