Application Continuity – A Database Feature for Developers

Application Continuity in Oracle Database 19c

Envision users running an application and not dreading ‘planned outages’ or wondering why their latest data entry disappeared into a black hole. Imagine you could make some simple configuration changes and all those problems would just go away. This is when you configure Application Continuity (AC) so that your users will no longer be impacted by rolling patching, database configuration changes or even the rare database crashes.

What does Application Continuity do?

Application Continuity hides disruptions in the database tier from the application and end-users. It effectively masks rolling patching activities, network failures, database instance stalls and crashes, switchovers to Active Data Guard standby databases and many other previously disruptive events. With Application Continuity configured, users will no longer be subject to planned downtime or unexpected outages. They can simply continue working without knowing that planned or unplanned events are transpiring behind the scenes.

How does it work?

Application Continuity replays database requests (transactions or queries, regardless) exactly as they were originally submitted, to ensure a result consistent with the request. For each request, it does so by first restoring and validating the session on a surviving database instance and then replaying the statements from the request to completion and returning the results to the user.

Mutables (functions that return new values each time they are referenced) are accounted for, including calls to SYSDATE and SEQUENCES (NEXTVAL). For instance, this means that if a call for NEXTVAL from a sequence returns 47 in the original processing of the request, the replay of that request must also use 47 for that value. AC also guarantees that any transactions being replayed will only be committed once, ever. This is accomplished through calls to Transaction Guard, providing the functionality to track and manage all transaction states during the replay.

Which Application Stacks & Configurations are supported?

Application Continuity (AC), first available for JDBC thin applications with Oracle Database 12.1, requires the use of an Oracle connection pool (such as the Universal Connection Pool for JDBC clients or the OCI Session Pool). Support for OCI and ODP.NET were added in Oracle Database 12.2. Oracle connection pools can also be configured for third-party application stacks, such as IBM WebSphere, RedHat JBoss and Apache Tomcat.

Transparent Application Continuity (TAC), introduced with Oracle Database 18c and further enhanced in Oracle Database 19c, extends support to application configurations that do not use Oracle connection pools (though they are still the preferred solution). This configuration significantly broadened the availability of the replay functionality to many more application stacks and is therefore another reason to upgrade to Oracle Database 19c. TAC is enabled by default for Oracle Autonomous Database and can be easily configured in the Oracle Cloud.

Are any application or database changes required?

No. No code changes are required for well-behaved applications.

Configuration changes are the limit of what must be done to enable database requests to be replayed via Application Continuity. Two simple steps configure applications for protection by Application Continuity:

1. Use the recommended TNS connect string for continuous availability:

Alias (or URL) =
(DESCRIPTION =
   (CONNECT_TIMEOUT=120) (RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=standby-scan)(PORT=1521)))     
(CONNECT_DATA=(SERVICE_NAME = YOUR SERVICE)))

2. (a) If using a JDBC thin client, replace the .jar files with the most recent set from Oracle. This set will include the ons.jar, the ucp.jar and the replay driver (ojdbcX.jar, where the X is either 8 or 11). These must be replaced as a set to insure correct interoperability.

(b) If configuring for an OCI client, replace all occurrences of OCIStmtPrepare with OCIStmtPrepare2 (OCIStmtPrepare was deprecated in 12.2 and will not be replayed). In addition, add HA EVENTS = TRUE to the recommended connection string, and ensure that the dba has configured the database service with aq_ha_notifications = True.

On the database level, only 3 simple configuration steps are required:

1. Configure database services for either the Application Continuity or the Transparent Application Continuity configuration. These services should be tailored specifically to the application workloads that they support.

The following shows how to configure a service for Transparent Application Continuity (TAC):

$ srvctl add service -db mydb -service GOLD –preferred inst1 -available serv2 -failover_restore AUTO -failoverretry 1 -failoverdelay 3 -commit_outcome TRUE -failovertype AUTO -replay_init_time 600 -retention 86400 -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE

2. Grant KEEP privileges on Mutables. Specifically, grant a “keep” on sequences that will be accessed.

3. Open port 6200 (or configure for an alternative) for ONS notifications.