Ensuring Application Continuity

Application Continuity is a feature that enables the replay, in a non-disruptive and rapid manner, of a request against the database after a recoverable error that makes the database session unavailable so an outage appears to the user as no more than a delayed processing of the request.

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.

To use this chapter, you should be familiar with the major relevant concepts and techniques of the technology or product environment in which you are using Application Continuity, such as Oracle RAC or Oracle Active Data Guard (Oracle ADG).

Understanding Application Continuity

Application Continuity masks many recoverable planned and unplanned Oracle AI Database outages by rebuilding database sessions, restoring session and transactional state, and replaying in-flight work without duplicating committed transactions. It relies on Transaction Guard and logical transaction identifiers to determine commit outcomes, supports Oracle RAC, Active Data Guard, DBMS_ROLLING, and multitenant PDB failover, and uses concepts such as database requests, request boundaries, recoverable errors, preserved function results, session-state consistency, and stateless applications. Replay replaces the failed session, restores state, validates results, and resubmits the final call; successful replay is transparent, while unsafe or inconsistent replay returns the original error. Support is available across numerous JDBC, UCP, OCI, ODP.NET, SQL*Plus, WebLogic, Tuxedo, Python, and Node.js configurations, while restrictions apply to unsupported drivers, certain APIs, serializable isolation, data-loss targets, replication technologies, and statements or operations that cannot be safely replayed. Request boundaries provide the strongest control over replay, whereas Transparent Application Continuity can discover boundaries for simpler applications.

Transparent Application Continuity

Transparent Application Continuity extends Application Continuity for simpler applications by automatically tracking session and transactional state, discovering implicit request boundaries, restoring preset state, preserving supported function values, and disabling replay when unsafe side effects are detected. Enabled with FAILOVER_TYPE=AUTO, TAC supports planned and unplanned failover, resumable cursors in Oracle AI Database 26ai, automatic session-state verification, and safe recovery without application code changes. It offers correctness guarantees including timely failover, validation of database identity and chronology, prevention of duplicate transactions, restoration of session state, and preservation of already observed results. TAC differs from traditional Application Continuity by creating request boundaries when sessions are transaction-free, restorable, and have suitable cursors, while RESET_STATE prevents state leakage between pooled uses. It is enabled by default on selected Oracle Cloud services and can be configured through DBMS_APP_CONT_ADMIN to enable TAC or AC, disable failover, activate coverage checks, reset state, and configure draining.

Configuring Application Continuity

Configuring Application Continuity requires suitable client and server resources, connection pools or explicit request boundaries, correct session-state restoration, appropriate service attributes, FAN, database services, retry settings, and monitoring of protection coverage. Administrators should select TAC with FAILOVER_TYPE=AUTO for applications with uncertain or evolving state usage, or AC with FAILOVER_TYPE=TRANSACTION when explicit boundaries and replay behavior are controlled; configure COMMIT_OUTCOME, FAILOVER_RESTORE, session-state consistency, replay timeouts, and connection retry parameters. High-availability connections should use Oracle data sources, SCAN-based addressing, aligned REMOTE_LISTENER settings, and suitable timeout and retry values. Database configuration must include FAN/ONS where applicable and must avoid default database services. FAILOVER_RESTORE can restore common and extended session states, with database templates and encrypted dictionary credentials providing broader coverage; keystores may be configured through WALLET_ROOT or, less preferably, SQLNET.ORA. Connection labels and initialization callbacks are reserved for states not restored automatically, while side-effect rules determine whether PL/SQL side effects, autonomous transactions, and database links are replayed or suppressed.

Administering Application Continuity Operation and Usage

This page explains how to administer Application Continuity for planned maintenance, replay consistency, monitoring, session-state management, protection analysis, reconnection, and replay suppression. It recommends combining FAN-aware connection pools with service draining, using Application Continuity to recover incomplete requests, and configuring appropriate service parameters for RAC or single-instance databases. It describes automatic and explicit preservation of mutable function results, methods for checking and granting KEEP privileges, protection-level statistics, AUTO and DYNAMIC session-state consistency, and Application Continuity statistics. The page also introduces ACCHK for tracing, filtering, reporting, and purging protection data, and documents conditions requiring replay to be disabled, including external side effects, interdependent sessions, middle-tier time logic, changing physical identifiers, and DBA-initiated termination with NOREPLAY.

Fast Application Notification (FAN)

This page describes FAN as Oracle RAC’s event-notification framework for rapidly informing clients about database, instance, node, network, and service availability changes. FAN prevents TCP timeout delays, supports immediate client interruption and reconnection, drains sessions during planned maintenance, enables connection-pool load balancing, and works with Oracle drivers, UCP, WebLogic, OCI, JDBC, and ODP.NET. It explains client and service configuration requirements, FAN-aware driver behavior, server-side callouts, high-availability event types and parameters, service subscriptions, and event-to-session mappings. FAN callouts can automate logging, alerting, service management, failback, and repair actions; they are installed on cluster nodes and generally execute on the originating node, except for node-down and VIP-down events, which are posted across the cluster.

Configure for Unplanned Outages

This page explains how Oracle RAC, FAN, and Application Continuity cooperate to conceal unplanned outages from applications by recovering in-flight work and relocating services across available instances. Clusterware isolates failed components, restores dependent resources, and maintains service cardinality where possible, while FAN publishes availability events through Oracle Notification Service and Advanced Queuing and can trigger server-side callouts. Applications remain independent of service placement because restart and recovery of databases, listeners, ASM, and related subsystems are automated. FAN callouts may integrate with fault-management and repair systems, although their asynchronous execution does not guarantee ordering.

Managing Planned Maintenance

Oracle RAC supports planned maintenance by relocating, stopping, and restarting services while draining active sessions at safe request boundaries to minimize disruption. FAN planned notifications, connection pools, server-side draining, configurable drain timeouts, and stop options coordinate session release and failover. The MAA Client Dashboard and views such as GV$CLIENT_HA_READINESS, GV$CLIENT_REQUEST_HISTOGRAM, and GV$SERVICE_DRAIN_TIMEOUT_ADVICE help assess client readiness, request durations, and suitable drain windows. Intelligent Drain Timing can automatically choose between continued draining and planned failover for protected sessions. SRVCTL supports maintenance operations for individual services, service groups, nodes, databases, instances, and PDBs, while Application Continuity, Transparent Application Continuity, TAF, connection tests, and specialized XA/sessionless transaction rules help preserve application work during service relocation or shutdown.

Transaction Guard for Improving Client Failover

Transaction Guard helps applications determine the outcome of a commit after a recoverable error, preventing duplicate transaction submissions and supporting transaction idempotence through Logical Transaction IDs. Database Native Transaction Guard uses database transaction identifiers to provide the same protection with lower overhead and is enabled by default with Application Continuity. Transaction Guard also supports XA transactions and DBMS_ROLLING upgrades by replicating transaction history to a transient logical standby, preserving commit outcomes during switchover. Configuration requires appropriate privileges, transaction-history planning, COMMIT_OUTCOME and RETENTION_TIMEOUT service settings, and preferably FAN; services should be explicitly configured with these parameters rather than using the default administrative database service.

Application Continuity During Major Database Version Upgrades with DBMS_ROLLING

Starting with Oracle AI Database 26ai, Application Continuity and session draining support planned major-version upgrades, restructuring, and non-rolling patching through DBMS_ROLLING. Sessions can fail over transparently between logical database versions during the controlled switchover, allowing applications to remain operational while the infrastructure monitors replication lag and initiates the transition when it can complete in seconds to minutes. The capability integrates Application Continuity with a logical standby to minimize interruption and maintain business continuity, with the 19c-to-26ai upgrade supported for Oracle Autonomous Database Dedicated only.

Reset Database Session State

RESET_STATE prevents session state from leaking between pooled application requests and, starting with Oracle AI Database 26ai, operates independently of Application Continuity. At request boundaries it can clear residual state, protecting shared connections from exposing sensitive application context and improving safety with Transparent Application Continuity. NONE performs no cleanup, LEVEL1 clears non-restorable state such as package variables, temporary objects, cursors, MLE variables, sequences, and DBMS_OUTPUT, and LOGIN additionally restores login-time settings including initialization parameters, application contexts, roles, tracing attributes, client identifiers, and database links. LOGIN requires explicit request boundaries, and RESET_STATE supersedes RESET_PACKAGE.