About Application High Availability Levels

Depending on your application's high availability requirements, you can implement the level of high availability (HA) protection that you need.

HA protection levels are defined in the table below, and each increase in level builds upon the previous level.

HA Level	Configuration	Experience	Benefits
Level 1: Basic Application High Availability See Configuring Level 1: Basic Application High Availability	Database or Security Administrator: Configure role-based database services Leverage recommended database connection string, and optionally configure LDAP and wallets Enable Fast Application Notification (FAN) for immediate interrupts during outages Application Developer: Use MAA recommended connect string Use Basic exception handling Implementation effort: Minimal - estimated 1 hour for administrator, and less than 1 hour for developers	Implementing Level 1 protection provides significant benefits compared to third party application failover solutions due to application + Oracle integration and intelligence to reduce application impact. Reduced application downtime Applications see errors during planned maintenance and unplanned outages, and automatically reconnect to another Oracle RAC instance or database with the target service Applicable for unplanned outages and planned maintenance. In some cases, long running transactions should be deferred or suspended during planned maintenance.	High availability with application automatically failing over and reconnecting Quick timeouts and automated connection retry with database connect string Location transparency with services: role-based services for standby and read-only databases so that applications are automatically routed to the proper instance with the correct role FAN auto-configured with database connect string Immediate interrupt on outages when using FAN (no need to tune timeouts and wait for them) Clusterware is aware of RAC and VIP health, so there is no waiting on downed end points thanks to FAN
Level 2: Prepare Applications for Planned Maintenance See Configuring Level 2: Prepare Applications for Planned Maintenance	Level 1 configuration + Application Developer: Use Oracle connection pools or connection tests and return your connection to the pool between uses Additional implementation effort for developers: Minimal effort with Oracle Connection pools - up to hours of effort when using an application server (or days when not using an application server depending on application complexity) for developers to identify connection tests used in the application and possibly create new ones in the database	Avoids errors during planned maintenance (errors still possible for unplanned outages) Ability to drain and move workload gracefully without application interruption Applicable for unplanned outages and planned maintenance events. In some cases, long running transactions should be deferred or suspended during planned maintenance.	Workload moves gracefully across instances with a slight delay and no errors during planned maintenance
Level 3: Mask Unplanned and Planned Failovers from Applications See Configuring Level 3: Mask Unplanned and Planned Failovers from Applications	Level 1 and 2 configuration + "Application Continuity" Solution Database or Security Administrator: Additional security and privileges required Application Developers: External actions (for example, side effects) outside the database need to be considered Additional implementation effort: Days to weeks of collaboration between developers and database administrators to review protection coverage (depending on application complexity)	In-flight transactions automatically acknowledge the commit or replay without application code changes Database administrators and application developers coordinate to ensure readiness using AWR statistics to assess protection coverage, and use ACCHK (application continuity health check) to identify coverage or exceptions when transactions can or cannot be replayed	Masks unplanned and planned fail overs from applications Applications avoid seeing errors during planned maintenance and outages In-flight uncommitted transactions are replayed; committed transactions are acknowledged and not replayed

All of the HA Levels described in the table above are superior to connection management approaches using load balancers as single connection VIP endpoints for the following reasons:

• Smart Service Health and Intelligent Reconnect: Oracle Clusterware and Oracle Data Guard Broker closely monitor the health and state of the clusters and databases to ensure connections are routed to the database service that is opened on a primary.
• Transparent and Automatic Failover: There is no need to query the health of databases and decide which is the proper one to move a VIP; everything is transparent in the high availability approaches described in the table.
• Fast Notification and Automatic Connection Retries: The disconnection of already connected sessions is immediate, and happens intelligently when Oracle Clusterware and Data Guard Broker detect outages or role changes on the primary and standby databases.

Terms

The following terms are used throughout this document:

• Draining: Move a connection from one instance to another available instance.

  Draining to move sessions gracefully from one instance to another is used during planned maintenance and load rebalancing. The connection is moved when the application returns the connection to a pool and then obtains a new connection or another rule is satisfied.

• Fail over: Reestablish an equivalent session at a new instance that offers the service.

  Fail over occurs during unplanned outages and during planned maintenance when sessions do not drain within an allotted period of time. The application should not receive errors when Application Continuity is configured.

Software Recommendations

The following software is recommended for HA Level configurations:

• Oracle Real Application Clusters (Oracle RAC) and Oracle Clusterware (which provides services and infrastructure to efficiently manage outages), preferably with Oracle Grid Infrastructure (GI) release 19c or later
• Oracle Active Data Guard is recommended for protection from database, cluster, storage or site failures
• Oracle Database 19c client and database or a later long-term support version, with the most recent patch level