Configuring Level 3: Mask Unplanned and Planned Failovers from Applications

Building on Level 1 and Level 2, Application Continuity is highly recommended to mask database interruptions from the applications and to handle timeouts and outages.

Database interruptions from the applications can include application workload that won't drain (planned failover). Application Continuity is enabled on the database service where it can be configured to operate in two modes, AC and TAC.

Application Continuity (AC)

Application Continuity hides outages, starting with Oracle Database 12.1 for JDBC thin applications, and Oracle Database 12.2.0.1 for OCI and ODP.NET applications with support for open-source drivers, such as Node.js, and Python, beginning with Oracle Database 19c.

Application Continuity rebuilds and recovers the session from a known point, which includes session states and transactional states, then it replays all interrupted in-flight work (if it is already committed, it is not replayed). When the replay is complete, the results are returned to the application as if no interruption occurred.

Application Continuity is recommended for OLTP applications using an Oracle connection pool. It is enabled on the database service through which the application is connecting to the database.

Transparent Application Continuity (TAC)

Starting with Oracle Database19c, Transparent Application Continuity (TAC) automatically tracks and records the session and transactional states, so the database session can be recovered and rebuilt following recoverable outages. This is done with no reliance on application knowledge or application code changes, allowing you to enable TAC for your applications.

Application transparency and failover are achieved by consuming the state-tracking information that captures and categorizes the session state usage as the application issues calls to the database. Set FAILOVERTYPE to AUTO on your service.

If you are not using an Oracle connection pool (as with SQL*PLUS), or you do not have knowledge about the application, then enable TAC on your database service.

Planned Failover with AC and TAC

Planned failover is failover that is invoked by the Oracle Database at points where the database decides that a session is replayable and is expected not to drain.

Planned failover is enabled by default when using AC or TAC. It improves situations where other draining methods are not active, for example, because FAN or connection tests are not configured.

Planned failover expedites maintenance by failing over early when replay is enabled.

For example, planned failover with TAC is the maintenance solution used with SQL*Plus.

Return Connections to the Connection Pool

Request boundaries are required for Application Continuity (AC) and are recommended for Transparent Application Continuity (TAC).

Using an Oracle connection pool, such as Universal Connection Pool (UCP) or OCI Session Pool, the request boundaries are automatically embedded in the session for you, without changing the application, at appropriate points. The application should return the connection to the Oracle connection pool when the unit of work, the database request, is completed in order to insert the end of request boundary. This also applies to using ODP.Net Unmanaged Provider, WebLogic Active GridLink, and RedHat.

Transparent Application Continuity (TAC), in addition, will discover request boundaries. The conditions for discovering such a boundary in Oracle Database 19c are:

No transaction is in progress
Cursors are returned to the statement cache or canceled (cursor does not remain open across transactions)
No un-restorable session state exists (PL/SQL globals, OJVM, populated temporary tables)

Set FAILOVER_RESTORE on the Service

To restore your session state at failover, set the attribute FAILOVER_RESTORE on your database service.

An application can be written to change the database session state (using ALTER SESSION commands typically), and these states need to be in place if you want the work to be replayed after failover.

In the service configuration, use FAILOVER_RESTORE LEVEL1 for Application Continuity, or FAILOVER_RESTORE AUTO for TAC. Following the application HA Level 1 steps, the service is created with FAILVOERTYPE AUTO which automatically sets FAILOVER_RESTORE AUTO.

The use of wallets is highly recommended; AC and TAC leverage wallets to ensure all modifiable database parameters are restored automatically with FAILOVER_RESTORE. Wallets are enabled for ADB-D and ADB-S and are the same as those used for database links.

Restore Original Function Values During Replay

Oracle Database 19c keeps the values of SYSDATE, SYSTIMESTAMP, SYS_GUID, and sequence.NEXTVAL, CURRENT_TIMESTAMP, and LOCALTIMESTAMP for SQL during replay.

If you are using PL/SQL, then GRANT KEEP for application users, and use the KEEP clause for a sequence owner. When the KEEP privilege is granted, replay applies the original function result at replay.

SQL> GRANT KEEP DATE TIME to scott;
SQL> GRANT KEEP SYSGUID to scott;
SQL> GRANT KEEP SEQUENCE mySequence on mysequence.myobject to scott;

Side Effects

When a database request includes an external call from the database, such as sending MAIL or transferring a file, this is termed a side effect.

When replay occurs, there is a choice as to whether side effects should be replayed. Many applications want to repeat side effects such as journal entries, sending mail, and file writes. For Application Continuity, side effects are replayed, but can be programmatically avoided. Conversely, Transparent Application Continuity does not replay side effects.

JDBC Configuration

Use oracle.jdbc.replay.OracleDataSourceImpl in a standalone manner, or configure it as connection factory class for a Java connection pool (such as UCP) or a WebLogic AGL Server connection pool.

See Configuring the Data Source for Application Continuity in Oracle Universal Connection Pool Developer's Guide for information about enabling AC/TAC on UCP. You would configure the JDBC driver data source class oracle.jdbc.replay.OracleDataSourceImpl as the connection factory class on the UCP data source PoolDataSourceImpl.

Note that the exact data source and connection pool configuration is always specific to a particular vendor product, such as 3rd-party connection pool, framework, application server, container, for example.

Monitoring

Application Continuity collects statistics to monitor your protection levels.

These statistics are saved in the Automatic Workload Repository (AWR) and are available in Automatic Workload Repository reports. Review the statistics to determine the extent of protected calls or If the protected call count or protected time decreases. Use the ACCHK utility for details as to the cause.