Transparent Application Continuity

A version of Application Continuity for simple applications that uses discovery to detect request boundaries.

About Transparent Application Continuity

In Oracle Database both Application Continuity and Transparent Application Continuity transparently tracks and records session and transactional state so that a database session can be recovered following recoverable outages.

Transparent Application Continuity uses this information to discover boundaries for basic applications. Recovery of the user database session is done safely and with no need for a DBA or developer to have any knowledge of the application or make application code changes. Transparency is achieved by using a state-tracking infrastructure that categorizes session state usage as an application issues user calls.

Transparent Application Continuity is enabled when FAILOVER_TYPE=AUTO.

You can enable Application Continuity or Transparent Application Continuity to protect applications during planned maintenance and when unplanned outages occur. For planned maintenance, database sessions that reach a safe place (such as a connection test or a known recoverable point) are drained at the database. For database sessions that do not drain, the database determines when to fail the database session over and triggers Transparent Application Continuity or Application Continuity to do so. Application Continuity hides unplanned outages for Java-based applications, OCI and ODP.NET applications including SQL*Plus, all Oracle connection pools, Tuxedo, WebLogic Server, and third-party application servers using Universal Connection Pool.

Starting with Oracle AI Database 26ai, Transparent Application Continuity (TAC) includes Transparent Application Failover (TAF) style cursors, known as Resumable Cursors. TAC supports basic SELECT cursors in FETCH. To support SELECT cursors in FETCH, not in transactions, set session state consistency to AUTO. In addition, the database repositions these cursors at failover for much faster failover. TAC provides higher protection because cursors can remain open across transaction boundaries. This provides better-unplanned outages and planned maintenance support for applications. It allows TAC to re-enable faster to provide higher protection and achieves speedier failover.

For unplanned outages, Transparent Application Continuity is invoked for outages that result in recoverable errors, typically related to underlying software, foreground, hardware, communications, network, or storage layers, hiding most failures from applications and users.

TAC supports basic applications using SQL and basic ALTER SESSION statements. With Transparent Application Continuity, DBAs no longer need to have knowledge of an application to:

Restore preset states-At run time, Transparent Application Continuity records the initial preset session states, monitors further states, and records session signatures sufficient to detect deviation in the state of a session at failover for monitored states. At failover, Transparent Application Continuity restores the preset session states before replay starts, and verifies that these session states fully match the original before replay starts. This also allows for session state that has been restored using both Application Continuity and other mechanisms, such as log-on triggers, labels, and connection call backs. You will continue to add log-on triggers, call backs, or labels if the state is outside the preset states.
Recognize and disable application-level side effects when recovering a session-Transparent Application Continuity records the transactions and session state from the client, which is referred to as capture, to enable replay. During normal run-time, Transparent Application Continuity detects side effects, or changes that occur as a result of the transaction, but are not part of the transaction itself. The type of side effect is distinguished between those that relate to an application's logic and those that are internal, relating to database housekeeping. For applications that use statements that have side effects, capture is disabled when the statement is running. Once a new request starts, capture is re-enabled automatically.
Restore original function values: Application Continuity preserves original values for supported mutable functions and sequences during replay. This handling is automatic for top-level SQL starting with Oracle Database 19c and for anonymous PL/SQL starting with Oracle AI Database 26ai. See Restoring Original Oracle Function Values and Application Continuity.
Know about request boundaries-Request Boundaries demarcate where applications and application servers borrow and return connections from their connection pools. For applications using Application Continuity with the JDBC thin driver, OCI, and ODP.NET Unmanaged Provider, DBAs do not need to know about request boundaries but when they are in use, Transparent Application Continuity takes advantage of them. As a best practice, use explicitly delineated request boundaries in your application because it is not always possible for the database to identify a checkpoint where a request boundary can be inserted.
Using Transparent Application Continuity, the server and the drivers are tracking transaction and session state usage. This allows the driver to detect implicit request boundaries. For an implicit boundary with SSS cursors, no objects may be open, cursors must have been returned to the statement cache, no transaction may be active, and the session state must have been recognized as fully restorable. The driver either discards the currently tracked information, and starts tracking again from this point, or it re-enables tracking if there had been a disabling event. On the next call to the server, the server verifies and, if applicable, creates a request boundary where there was previously no explicit boundary.
To use Transparent Application Continuity for more complex applications with unrestorable session states, use a pool like you use for Application Continuity and set RESET_STATE to clean the session state between usages. RESET_SATE is suitable for applications that must not leak session state from one pooled usage to a later usage.

Deciding on Transparent Application Continuity

Transparent Application Continuity (TAC) is an application failover solution that is safe to enable by default.

TAC provides failover for planned events, called planned failover, as well as for unplanned events. Refer to Oracle AI Database High Availability Overview and Best Practices to know more about planned and unplanned failover and Oracle Maximum Availability Architecture (MAA) levels.

A successful failover is a delayed execution, with no error returned to the application. If TAC cannot produce the same logical session, TAC returns an error to the application. The correctness guarantees for a successful failover includes the following, but not limited to:

Within the SLA set for the service under replay_initiation_timeout - Failover starts if the timestamp for the failover is less than or equal to replay_initiation_timeout , where replay_initiation_timeout is set at the start of the request.
Same database forward in time- The failover checks that the target database is at the correct database ( DBID or PDBID ) and is at the same time or is forward in time (called SCN ancestry) from the original.
No duplication of transactions- The failover checks whether the last request committed and if the request committed returns COMMITTED to the client.
Same session state at the start of replay as the original session- If replay is needed, after restoring the session state using FAILOVER_RESTORE and before replaying, the session states are checked to ensure that they match the original session at the start of the current request.
Same results that the application has already processed- Cursors are repositioned and the results of that repositioning are checked to be the same as before. This is similar to TAF with the difference that the reposition in Oracle AI Database 26ai is at the server with the rows no longer returned to the client. To provide higher success of same results, TAC keep original function results for sequences, date, time, and GUIDs.

TAC does this automatically for your application and declares success when it is correct to do so. This enables application developers to focus on business functionality while TAC handles the failover in the best possible way.

Know about planned failover?

With TAC enabled, the planned failover engine in the Oracle AI Database looks for places where it is confident to failover and initiates the failover. This bounds your drain time and aims to prevent sessions from being aborted. This is automatic with both TAC and AC, but it is frequently with TAC.

Difference between TAC and AC (original)

AC needs request boundaries, which means AC depends on Oracle or third-party pools that embed request boundaries when connections are borrowed and returned to the pool. Whereas, TAC uses provided request boundaries and creates its own. With TAC request boundaries advance automatically when there is no transaction, the session state is restorable, and cursors are closed.

AC provides similar correctness guarantees for a successful failover as TAC, with a small variation. AC enforces same client visible session states at the start of replay as the original session. AC replays side effects, such as sending email by default. TAC does not replay side effects as the default. The action for side effects is customizable in Oracle AI Database 26ai.

TAC request boundaries

TAC creates its own request boundaries, when:

There is no transaction.
The session state is restorable (no PL/SQL global variables, temporary tables, OJVM, and session duration LOBs)
The cursors are resumable in Oracle AI Database 26ai or closed

Cleaning sessions for next usage

The service attribute RESET_STATE cleans your session state and cursors at the end of each request so these states do not leak to later requests. RESET_STATE saves you work and is future proofed, meaning that later changes to your application are also cleaned. It allows TAC to re-enable if TAC was unable to clean a session due to not restorable states.

Using Transparent Application Continuity in Oracle Cloud Environments

Transparent Application Continuity is enabled by default on TP and TPURGENT services in an Oracle Cloud environment for Oracle Autonomous AI Database-Dedicated, and is available for Oracle Autonomous AI Database-Serverless.

In Oracle Cloud environments, the use of FAILOVER_RESTORE and wallets means that you should not have to add callbacks to set initial state.

There are two features that work together to enable Transparent Application Continuity automatically:

For planned outages, sessions that reach a safe place for transactions are drained from the instance and automatically failed over to another instance. For sessions that do not drain, Oracle AI Database determines where to fail over the session and invokes Application Continuity to fail over the session.
For unplanned outages, Transparent Application Continuity transfers the user sessions to a remaining instance, hiding the outage from users automatically without having to understand or change the application.

Enable Application Continuity on Your Service

You can change the service attributes specified on your service by using the generic package DBMS_APP_CONT_ADMIN. Use this procedure to enable Application Continuity or Transparent Application Continuity, or to disable failover. New sessions will use the new failover type. You must have the PDBADMIN user permissions to use these procedures. Use the full service name in these examples.

Use the dbms_app_cont_admin.enable_tac('TPURGENT') procedure to enable Transparent Application Continuity for your service:
```
SQL> execute dbms_app_cont_admin.enable_tac('TPURGENT');
```
Use the dbms_app_cont_admin.enable_ac('TPURGENT') procedure to enable Application Continuity for your service:
```
SQL> execute dbms_app_cont_admin.enable_ac('TPURGENT');
```
Use the dbms_app_cont_admin.disable_failover('HIGH') procedure to disable failover for your service:
```
SQL> execute dbms_app_cont_admin.disable_failover('HIGH');
```
Use the dbms_app_cont_admin.acchk_set procedure to enable ACCHK for your service:
```
SQL> execute dbms_app_cont_admin.acchk_set(true);
```

Use the dbms_app_cont_admin.acchk_set_filter procedure to set ACCHK filter for your service:

SQL> execute dbms_app_cont_admin.acchk_set_filter(DBMS_APP_CONT_ADMIN.SERVICE_FIL
TER, 'TPURGENT');

Use the dbms_app_cont_admin.enable_reset_state procedure to enable RESET STATE for your service:
```
SQL> execute dbms_app_cont_admin.enable_reset_state('TPURGENT', 'LEVEL1');
```
Use the dbms_app_cont_admin.set_draining procedure to configure draining for your service:
```
SQL> execute dbms_app_cont_admin.set_draining('TPURGENT', 300, 'IMMEDIATE');
```