Skip Headers
Oracle® Database Development Guide
12c Release 1 (12.1)

E17620-15
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

26 Ensuring Application Continuity

Application Continuity is a feature that enables the replay, in a nondisruptive and rapid manner, of a request against the database after a recoverable error that makes the database session unavailable. The request can contain transactional and nontransactional work. After a successful replay, the application can continue where that database session left off, instead of having users left in doubt not knowing what happened to their funds transfers, flight bookings, and so on, and avoiding the need to reboot mid-tier machines to recover from logon storms. With Application Continuity, the end user experience is improved by masking many outages, planned and unplanned, without the application developer needing to attempt to recover the request.

Without Application Continuity, it can be almost impossible for an application to mask outages in a safe way, for reasons that include the following:

Application Continuity, however, does this work for the application developer, thus masking many outages in a safe way.

Application Continuity improves developer productivity by attempting to mask outages that can be masked. However, applications still must include error handling for these cases:

Introduced in Oracle Database 12c Release 1 (12.1.0.1), Application Continuity strengthens the fault tolerance of systems and applications that use an Oracle database.

Currently, the terms "Application Continuity" and the named feature "Application Continuity for Java" are synonymous, for purposes of this chapter.

This chapter assumes that you are familiar with the major relevant concepts and techniques of the technology or product environment in which you are using Application Continuity, such as Oracle WebLogic Server, Oracle RAC, or Oracle Active Data Guard (Oracle ADG).

Topics:

26.1 About Application Continuity

Application Continuity attempts to mask many recoverable database outages (when replay is successful) from applications and users by restoring the database session: the full session, including all states, cursors, variables, and the last transaction if there is one.

Application Continuity addresses the problem that arises when an application is trying to access the database and the database session becomes unavailable due to an unplanned or planned outage (timeout, network outage, instance failure, repair, configuration change, patch apply, and so on). Without Application Continuity in place, database recovery does not mask outages to applications and end users. In such scenarios, developers and end users must cope with exception conditions, and end users can be left not knowing what happened to their funds transfers, time sheets, orders, bill payments, and so on. Users might lose screens of uncommitted data, and must log in again and reenter that data. In the worst cases, the administrator might be forced to restart the middle tier to recover from the logon storm.

With Application Continuity, if the database session became unavailable, Application Continuity attempts to rebuild the session and any open transactions using the correct states; and if the transaction succeeded and need not be reexecuted, the successful return status is returned to the application. If replay is successful, the request can continue safely without risk of duplication. If replay cannot restore data that the application has already processed and potentially made decisions on, the database rejects the replay and the application receives the original error.

Application Continuity performs the recovery of in-flight transactions and database session state, while ensuring the transaction idempotence provided by Transaction Guard. Each database session is tagged with a logical transaction ID (LTXID), so the database recognizes whether each replay committed any transactions, and if it did commit any transactions, whether the work also ran to completion. While Application Continuity attempts to replay, the replay appears to the application as a delayed execution, or the application receives the commit response for the original transaction (if the last transaction had completed before the outage).

Application Continuity is supported for Oracle Real Application Clusters (Oracle RAC), Data Guard, Active Data Guard, and WebLogic Server in conjunction with the JDBC Thin Driver or the Universal Connection Pool. It is supported for both nonconsolidated database and for consolidated databases (with consolidated database failover at PDB level). (It is not currently supported for Golden Gate, Logical Standby, or DML redirection if using Active Data Guard.) You can think of Application Continuity as a feature in Oracle Database that enables users of many Oracle technologies to benefit.

Topics:

See Also:

Oracle Database 2 Day + Real Application Clusters Guide for information about Transaction Guard and Application Continuity with Oracle RAC

26.1.1 Key Concepts for Application Continuity

This section describes several terms and concepts that you must understand to use Application Continuity. These terms are used throughout this chapter.

request

A request is a unit of work submitted from the application. It typically corresponds to the SQL and PL/SQL, and other database calls, of a single web request on a single database connection, and it is generally demarcated by the calls made to check-out and check-in the database connection from a connection pool. For recoverable errors, Application Continuity reestablishes the conversation state for a database session and repeats the request.

recoverable error

A recoverable error is an error that arises due to an external system failure, independent of the application session logic that is executing. Recoverable errors occur following planned and unplanned outages of foregrounds, networks, nodes, storage, and databases. The application receives an error code that can leave the application not knowing the status of the last operation submitted. Application Continuity reestablishes database sessions and resubmits the pending work for the class of recoverable errors.

Application Continuity does not resubmit work following call failures due to nonrecoverable errors. An example of a nonrecoverable error that would not be replayed is submission of invalid data values.

commit outcome

A transaction is committed by updating its entry in the transaction table. Oracle Database generates a redo-log record corresponding to this update and writes out this redo-log record. Once this redo-log record is written out to the redo log on disk, the transaction is considered committed at the database. From the client perspective, the transaction is considered committed when an Oracle message (termed Commit Outcome), generated after that redo is written, is received by the client. However, the commit message is not durable. (Transaction Guard, described in Chapter 25, obtains the commit outcome available when it has been lost.)

mutable objects

Mutable objects are nondeterministic function that can obtain a new value every time it is called, and thus their results can change frequently. Mutable objects cause a problem for replay because the results can change at replay. Consider sequence.NEXTVAL and SYSDATE, often used in key values. If a primary key is built with values from these function calls, and is used in later foreign keys or other binds, at replay the same function result must be returned.

Application Continuity provides mutable object value replacement at replay for granted Oracle function calls to provide opaque bind-variable consistency. If the call uses database functions that are mutable, including sequence.NEXTVAL, SYSDATE, SYSTIMESTAMP, and SYSGUID, the original values returned from the function execution are saved and are reapplied at replay.

session state consistency

After a COMMIT statement has executed, if state was changed in that transaction, it is not possible to replay the transaction to reestablish that state if the session is lost. When configuring Application Continuity, the applications are categorized depending on whether the session state after the initial setup is static or dynamic, and thus whether it is correct to continue past a COMMIT operation within a request.

  • A session has dynamic state if the session state changes are not fully encapsulated by the initialization, and cannot be fully captured in a callback at failover. After the first transaction completes, failover is internally disabled until the next request begins.

  • A session has a static state if all session state changes (for example, NLS settings and PL/SQL package state) occur as part of initialization, and can be encapsulated in a callback at failover.

26.2 Application Continuity Operation and Usage

This section explains how Application Continuity works, and how you can use it in applications.

Topics:

26.2.1 How Application Continuity Works for Database Sessions

If a recoverable error occurs and if replay is enabled, recovery of the database session is attempted. Application Continuity performs the major steps shown in Figure 26-1. The major steps apply for both unplanned and planned outages, although specific steps vary depending on the type of outage. (For example, for planned outages further optimizations are possible, as explained in Section 26.2.2.6, "Using Application Continuity for Planned Outages".)

Figure 26-1 How Application Continuity Works

Description of Figure 26-1 follows
Description of "Figure 26-1 How Application Continuity Works"

As shown in Figure 26-1:

  1. The client application makes a request, which is passed to a middle tier (such as the JDBC Thin driver, Universal Connection Pool, or WebLogic Server or third party pool) or directly to the database using the JDBC replay driver.

  2. The JDBC replay driver issues each call in the request.

  3. A FAN unplanned or planned down interrupt or recoverable error occurs. FAN/FCF then aborts the dead physical session.

  4. Application Continuity begins the replay and does the following:

    1. Replaces the dead physical session with a new clean session and rewires FAN in case a later error occurs during or after replay.

    2. Prepares for replay by using Transaction Guard to determine the outcome of the in-flight transaction if one was open.

    3. Optionally, calls back using a labeling callback or reconnect callback for the initial state.

    4. Rebuilds the database session, recovering the transactional and nontransactional states, and validating at each step that the data and messages seen by the client driver are the same as those that the client may have seen and used to make a decision.

    5. Ends the replay and returns to runtime mode.

    6. Submits the last queued call.

      This is the last call made when the outage was discovered. During replay, only this call can execute a COMMIT. A COMMIT midway through rebuilding the session aborts replay (excluding autonomous transactions).

  5. The response is returned to the application.

    If replay succeeded, the application can continue with the problem masked. If not, the application must handle the original error.

The behavior of Application Continuity after a communication failure depends on the Oracle products and technologies involved. For example:

  • If you use Oracle Real Application Clusters or an Active Data Guard farm, after the connection instance is reestablished on another running instance, Application Continuity attempts to rebuild the session and replay the last transaction if there is one in flight.

  • If you use Oracle Data Guard and fail over to a standby site, Application Continuity connects to the failover instance and attempts to rebuild the session and replay the last transaction there if a transaction was in flight. (Application Continuity does not replay if the Data Guard switchover or failover has lost data, and if this is not Active Data Guard reader farm with approved lags.)

  • If you are using Oracle RAC or Oracle RAC One and not using Data Guard, and if an outage causes a break in all public networks or causes the database or database session to shut down briefly, Application Continuity attempts to rebuild the session and replay the last transaction (if a transaction was in flight) against the database after connectivity is restored.

26.2.2 Actions for Using Application Continuity for Java

Application Continuity for Java is available for general use with the following Oracle technologies:

  • JDBC Thin Oracle replay driver

  • Universal Connection Pool

  • WebLogic Server Active GridLink

A main appeal of Application Continuity for Java is its ability to mask many outages when using the Oracle stack with few or no application changes. Applications must be verified and tested to ensure that they are suitable for replay before releasing with Application Continuity for Java. If you must perform any actions, in most cases these do not involve core application source code changes, but rather configuration changes or providing a callback to disable replay for any code module.

The Application Continuity for Java solution is embedded in Oracle Universal Connection Pool (UCP), and in the Oracle WebLogic Server Active GridLink and Generic data sources. When you use the Oracle connection pools, request boundaries are implicitly marked at check-out and check-in delimiting the size of each replay. However, when you are using third-party connection pools with Oracle JDBC Thin, or when you are using UCP or WebLogic Server but not returning connections to the pools, you may need to perform actions to obtain the benefits of Application Continuity for Java.

Support for Application Continuity is integrated into many Oracle applications, so the features in such applications are used automatically if you set the Application Continuity-related service attributes. For your own applications, however, you also must follow the steps described in this section.

The main actions for ensuring automatic application continuity for an application are the following:

  1. Determine whether the application uses Oracle JDBC concrete classes. For Application Continuity to be used, the deprecated concrete classes must be replaced. For information about the deprecation of concrete classes, including actions to take if an application uses them, see My Oracle Support Note 1364193.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1).

  2. Ensure that you have the necessary CPU and memory resources.

    • CPU: Application Continuity is managed on the client and server sides and needs additional CPU to operate.

      At the client, CPU is used to build proxy objects and for garbage collection (GC).

      At the server, CPU is used for validation. CPU overhead is reduced for platforms with current Intel and Sparc chips where validation is assisted in the hardware.

    • Memory: The replay driver requires more memory than the base driver because the calls are retained until the end of a request. At the end of the request, the calls are released to the garbage collector. This action differs from the base driver that releases closed calls.

      The memory consumption of the replay driver depends on the number of calls per request. If this number is small, then the memory consumption of the replay driver is less, and comparable to the base driver.

      To obtain the best performance, you must set the same value for both the -Xmx and -Xms parameters on the server. For example, if there is sufficient memory, then allocate 4 to 8 GB (or more) of memory for the Virtual Machine (VM), for example, by setting -Xms4g for 4 GB. If the -Xms parameter has a lower value, then the VM also uses a lower value from the operating system, and performance might suffer and garbage collection operations increase.

  3. Determine whether the application borrows and returns connections from the WebLogic Server Pool or Universal Connection Pool for each request, or whether to add beginRequest and endRequest APIs to the application's own connection pool to identify request boundaries.

    (Do not use beginRequest and endRequest anywhere other than at request boundaries (check-in). endRequest indicates that the request is complete, and that it is now stateless. Replay starts from the next beginRequest. If there is prior state, it must be reestablished in the callback.)

  4. Decide whether to use an optional callback for initializing connections. When using Oracle WebLogic Server or the Universal Connection Pool, connection labeling is recommended. The labeling is used for both runtime and replay.

  5. Determine whether the application requires, and therefore needs to configure keeping original values for, SYSDATE, SYSTIMESTAMP, and SYS_GUID and sequences during failover (see Section 26.2.3, "Mutable Objects and Application Continuity").

  6. Assess the application style for the session_state_consistency value, and set the appropriate value on the service:

    • If session_state_consistency is Dynamic, the application changes the environment or settings during the request. Replay is disabled after the first COMMIT until the end of replay API is called. Dynamic is the default mode, appropraite for most applications.

    • If session_state_consistency is Static, the application never changes the session state after initial setup. This mode is typical for database agnostic applications that do not use PL/SQL state and do not use ALTER part-way through transactions. Use this mode with caution, and only for "static" applications.

    For more information, see Section 26.2.4, "Session State Consistency," and Section 26.2.4.2, "Static Session State Consistency."

  7. Determine whether replay must be explicitly disabled for any code path.

    For example, replay may need to be disabled for requests using external PL/SQL actions (see Section 26.2.2.8, "Disabling Replay in Application Continuity for Java").

  8. Follow these configuration guidelines:

    • Use Oracle Database 12c Release 1 (12.1.0.1) or later.

    • Use Universal Connection Pool 12.1 (or later) or WebLogic Active GridLink 12.1.2 (or later) configured with the JDBC Replay data source; or for third party applications, including third party JDBC pools, use JDBC replay driver.

      Custom Java pools and standalone Java applications can use the JDBC Replay data source directly. When using custom Java pools and standalone applications, add the beginRequest and endRequest calls.

    • If the application does not borrow and return from the Oracle connection pools, explicitly mark request boundaries. For example, if using custom JDBC pools, WebSphere, TomCat, JBOSS, or other pools, then call beginRequest at check-out and call endRequest at check-in. These APIs can also be used for standalone JDBC applications without a connection pool.

    • Use a single pool with FAN/FCF from the WebLogic Data Source or UCP or third-party pool.

    • Use a database service to connect; never use a SID or an instance name.

    • Use a connection string that sets retries for new incoming connections and a delay between these retries.

    • For the service, set FAILOVER_TYPE to TRANSACTION, COMMIT_OUTCOME to TRUE, and Notification to TRUE. Optionally to find the best connections to use, set GOAL to SERVICE_TIME and CLB_Goal to Short.

Topics:

See Also:

26.2.2.1 When Is Application Continuity Transparent?

Application Continuity is transparent (performed automatically) for J2EE applications that use standard JDBC and that use Oracle connection pools (UCP or WLS Active GridLink). For applications with external actions (for example, autonomous transactions or using UTL_HTTP to issue an SOA call), Application Continuity is still transparent if the application's correctness is preserved when these external actions are replayed after a failure.

For other scenarios in which Application Continuity is not transparent, the following infrastructure changes may be needed:

  • If the connection pool or container does not use an Oracle connection pool, the application must use Application Continuity APIs to mark request boundaries. Request boundaries are needed to reclaim the memory used for holding calls, and to establish a point at which to resume recording following nonreplayable operations.

  • If the application has requests that the application does not want repeated, the application can explicitly call an API to disable replay for those requests. Such calls are likely to be isolated to one or a few specialized pieces of application code.

26.2.2.2 Configuring Oracle JDBC for Application Continuity for Java

You must use the oracle.jdbc.replay.OracleDataSourceImpl data source to obtain JDBC connections. This data source supports all the properties and configuration parameters of all the Oracle JDBC data sources, for example, the oracle.jdbc.pool.OracleDataSource.

You must remember the following points while using the connection URL:

  • If the REMOTE_LISTENER setting for the database does not match the addresses in the ADDRESS_LIST at the client, then it does not connect, showing services cannot be found. So, the REMOTE_LISTENER setting for the database must match the addresses in the ADDRESS_LIST at the client:

    • If REMOTE_LISTENER is set to the SCAN Names, then the ADDRESS_LIST must use SCAN VIPs.

    • If the connect string uses the SCAN Name, then REMOTE_LISTENERS must be set to the SCAN Name.

    • If the connect string uses an ADDRESS_LIST of host VIPs, then REMOTE_LISTENERS must be set to an ADDRESS list including all SCAN VIPs and all host VIPs

    Note:

    A motivation for using SCAN is location independence: the client need not be reconfigured when nodes are added or removed, or when databases change to running on different nodes.
  • Set RETRY_COUNT, CONNECT_TIMEOUT, and TRANSPORT_CONNECT_TIMEOUT parameters in the connection string. This is a general recommendation for configuring the JDBC Thin driver connections, starting from Oracle Database 11g Release 2 (11.2.0.2). These settings improve acquiring new connections at runtime, at replay, and during work drains for planned outages.

    The CONNECT_TIMEOUT parameter is equivalent to the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file and applies to the full connection. The TRANSPORT_CONNECT_TIMEOUT parameter is detemined by the ADDRESS parameter. If the service is not registered for a failover or restart, then retrying is important when you use SCAN. (Using Easy Connect is not recommended because Easy Connect does not support the RETRY_COUNT, CONNECT_TIMEOUT, and TRANSPORT_CONNECT_TIMEOUT parameters.)

    When the connect string uses host VIPs, then REMOTE_LISTENERS must include host VIPs. When the connect string uses the SCAN Name, then REMOTE_LISTENERS must be set to the SCAN Name, or include the SCAN VIPs and the host VIPs. Therefore, REMOTE_LISTENERS must be set to the SCAN Name unless any clients use host VIPs in their connect strings, in which case REMOTE_LISTENERS must be set to an ADDRESS_LIST of all SCAN VIPs and all host VIPs.

    See Also:

26.2.2.3 Configuring Oracle Database for Application Continuity for Java

Your Oracle Database configuration must include the following to use Application Continuity for Java:

  • If you are using Oracle Real Application Clusters (Oracle RAC) or Oracle RAC One, Oracle Data Guard, or Oracle Active Data Guard, then ensure that FAN is configured with Oracle Notification System (ONS) to communicate with Oracle WebLogic Server or the Universal Connection Pool (UCP)

  • Set the required properties on the service for replay and load balancing. For example, set:

    • FAILOVER_TYPE = TRANSACTION for using Application Continuity

    • REPLAY_INITIATION_TIMEOUT = n for setting the duration in seconds to allow replay to start (where n might be, for example, 60, 300, 900, or 1800, depending on your needs)

    • FAILOVER_RETRIES = 30 for specifying the number of connection retries for each replay

    • FAILOVER_DELAY = 10 for specifying the delay in seconds between connection retries

    • GOAL = SERVICE_TIME -- if you are using Oracle RAC or Oracle GDS (Global Data Services), then this is a recommended setting

    • CLB_GOAL = SHORT -- if you are using Oracle RAC or Oracle GDS, then this is a recommended setting

  • Do not use the database service, that is, the default service corresponding to the DB_NAME or DB_UNIQUE_NAME. The use of the database service is not recommended for high availability, because this service cannot be enabled and disabled, and cannot be relocated on Oracle RAC or switched over to Oracle Data Guard. This service is reserved for Oracle Enterprise Manager and for DBAs.

26.2.2.4 Registering a Connection Initialization Callback in Application Continuity for Java (optional)

Nontransactional session state (NTSS) is state of a database session that exists outside database transactions and is not protected by recovery. For applications that use stateful requests, the nontransactional state is reestablished as the session is rebuilt by Application Continuity.

For applications that set state only at the beginning of a request, or for stateful applications that gain performance benefits from using connections with a preset state, choose one of these callback options:

26.2.2.4.1 No Callback

In this scenario, the application builds up its own state during each request.

26.2.2.4.2 Connection Labeling

Connection Labeling is a generic pool feature that is recommended for its excellent performance. When Connection Labeling is present, Application Continuity uses it.

This scenario is applicable to Universal Connection Pool (UCP) and Oracle WebLogic server. The application can be modified to take advantage of the preset state on connections. Connection Labeling APIs determine how well a connection matches, and use a callback to populate the gap when a connection is borrowed.

26.2.2.4.3 Connection Initialization Callback

In this scenario, the replay driver uses an application callback to set the initial state of the session during runtime and replay. The JDBC replay driver provides an optional connection initialization callback interface and methods to register and unregister connection initialization callbacks in the oracle.jdbc.replay.OracleDataSource interface.

When registered, the initialization callback is executed at each successful reconnection following a recoverable error. An application is responsible for ensuring that the initialization actions are the same as that on the original connection before failover. If the callback invocation fails, then replay is disabled on that connection. Use the connection initialization callback only when the application has not implemented Connection Labeling.

26.2.2.5 Delaying the Reconnection in Application Continuity for Java

By default, when JDBC Replay Driver initiates a failover, the driver attempts to recover the in-flight work at an instance where the service is available. For recovering the work, the driver must establish a good connection with the instance. This reconnection can take some time if the database or the instance must be restarted before the service is relocated and published. So, the failover must be delayed until the service is available from another instance or database.

You must use the FAILOVER_RETRIES and FAILOVER_DELAY parameters to manage reconnecting. These parameters can work well in conjunction with a planned outage, for example, an outage that may make a service unavailable for several minutes. While setting the FAILOVER_DELAY and FAILOVER_RETRIES parameters, check the value of the REPLAY_INITIAITION_TIMEOUT parameter first. The default value for this parameter is 900 seconds. A high value for the FAILOVER_DELAY parameter can cause replay to be canceled.

Parameter Name Possible Value Default Value
FAILOVER_RETRIES Positive integer zero or above 30
FAILOVER_DELAY Time in seconds 10

The following examples show various failover scenarios:

26.2.2.5.1 Creating Services on Oracle RAC

If you are using Oracle RAC or Oracle RAC One, then use the SRVCTL command to create and modify services in the following way:

For Policy Managed Databases

srvctl add service -db codedb -service GOLD -serverpool ora.Srvpool -clbgoal SHORT -rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE

For Administrator Managed Databases

srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2  -clbgoal SHORT -rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE
26.2.2.5.2 Modifying Services on Single-Instance Databases

If you are using a single-instance database, then use the DBMS_SERVICE package to modify services in the following way:

declare
params dbms_service.svc_parameter_array;
begin
params('FAILOVER_TYPE'):='TRANSACTION';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
end;
/

26.2.2.6 Using Application Continuity for Planned Outages

For planned outages the recommended approach is to drain requests from Oracle connection pools in combination with Application Continuity for those requests that do not complete. Instances do need to be stopped to switch over to the patched software. This has the least impact when there is minimal recovery to complete.

The steps are the following:

  1. Use any FAN-aware pool: OCI, UCP, WebLogic Server, or ODP.Net.

    The FAN planned event drains at request boundaries.

  2. Use srvctl relocate to relocate the service from the instance without disrupting the sessions (no -force flag), or for a uniform service use srvctl stop service at the instance (no -force flag).

    • For Oracle RAC One, use relocate database (no -force flag).

    The FAN planned event clears the idle sessions immediately and marks the active sessions to be released at check in (end of request). This drains the sessions from the instance without disrupting work.

  3. If not all sessions have checked in and the time to stop the instance has been reached, stop the instance (abort).

    For Application Continuity enabled pools (UCP and WLS), and any pool that adds beginRequest/endRequest on the JDBC Thin replay driver, Application Continuity attempts to recover those remaining sessions.

  4. Restart the instance and service.

    Runtime load balancing, when enabled, balances the sessions back to the restored instance at the next request boundaries.

26.2.2.7 Running Without Application Continuity

Sometimes Application Continuity is not in effect, through deliberate choice, error, or oversight. Application Continuity is not in effect when it has not been started or when it has been disabled. If it has been disabled, it remains so through the endRequest call.

Application Continuity is not started when the service property FAILOVER_TYPE does not have the value set to TRANSACTION. For a planned outage, set the FAILOVER_TYPE value to TRANSACTION beforehand; the setting applies to new connections, and existing connections retain their original service value.

Application Continuity is disabled when any of the following occurs:

  • The application executes a statement that is restricted for Application Continuity (for example, if it uses Oracle JDBC concrete classes).

  • Application Continuity is explicitly disabled using disableReplay (see Section 26.2.2.8).

  • A COMMIT statement is issued when the service parameter session_state_consistency is set to Dynamic (the default).

  • An endRequest statement is issued until the next beginRequest is issued.

  • The session is killed or disconnected and the NOREPLAY keyword is specified (see Section 26.2.2.9).

  • A request issues an ALTER SYSTEM or ALTER DATABASE statement.

26.2.2.8 Disabling Replay in Application Continuity for Java

By default, the JDBC replay driver replays following a recoverable error. If the application has requests that the application does not want repeated, the application can explicitly call an API to disable replay for those requests. For example, if the application uses UTL_SMTP and does not want messages repeated, the disableReplay API is in effect for the request that must be disabled. All other requests continue to be replayed.

For applications with external actions (for example, autonomous transactions or using UTL_HTTP to issue an SOA call), Application Continuity remains transparent if the application's correctness is preserved when these external actions are replayed after a failure.

The following are scenarios to consider before configuring an application for replay:

26.2.2.8.1 Application Calls External PL/SQL Actions that Must Not Be Repeated

Autonomous transactions and external PL/SQL calls can have side effects that are separate from the main transaction, and these side effects are replayed unless you specify otherwise. Examples of side effects separate from the main transaction include writing to an external table, sending email, forking sessions out of PL/SQL or Java, transferring files, and accessing external URLs. Actions such as these leave persistent side effects. PL/SQL messaging can leave persistent results behind. For example, if a user walks away part way through some work without committing and the session times out or the user issues Ctrl+C, the foreground or a component fails; the main transaction rolls back while the side effects may have been applied. (For more information about side effects, see Section 26.3, "Potential Side Effects of Application Continuity".)

Application developers must decide whether to allow replay for external actions. Examples include using UTL_HTTP to issue an SOA call, or UTL_SMTP to send a message, or UTL_URL to access a website. If such external actions must not be replayed, use the disableReplay API.

26.2.2.8.2 Application Synchronizes Independent Sessions

You must not configure an application for replay if the application synchronizes independent sessions using volatile entities that are held until COMMIT, ROLLBACK, or session loss. For example, the application might synchronize multiple sessions connected to several data sources that are otherwise inter-dependent using resources such as a database lock. This synchronization may be acceptable if the application is only serializing these sessions and understands that any session may fail. However, if the application assumes that a lock or any other volatile resource held by one data source implies exclusive access to data on the same or a separate data source from other connections, then this assumption may be invalidated when replaying.

During replay, the driver is not aware that the sessions are dependent on one session holding a lock or other volatile resource. You can also use pipes, buffered queues, stored procedures taking a resource (such as a semaphore, device, or socket) to implement the synchronization that are lost by failures.

26.2.2.8.3 Application Uses Time at the Middle Tier in the Execution Logic

You must not configure an application for replay if the application uses the wall clock at the middle tier as part of the execution logic. The JDBC replay driver does not repeat the middle-tier time logic, but uses the database calls that execute as part of this logic. For example, an application using middle-tier time might assume that a statement executed at Time T1 is not reexecuted at Time T2, unless the application explicitly does so.

26.2.2.8.4 Application Assumes that ROWIds Do Not Change

If an application caches ROWIDs, then access to these ROWIDs might be invalidated due to database changes. Although a ROWID uniquely identifies a row in a table, a ROWID might change its value in the following situations:

  • The underlying table is reorganized.

  • An index is created on the table.

  • The underlying table is partitioned.

  • The underlying table is migrated.

  • The underlying table is exported and imported using EXP/IMP/DUL.

  • The underlying table is rebuilt using Golden Gate or Logical Standby or other replication technology.

  • The database of the underlying table is flashed back or restored.

It is bad practice, in general, for an application to store ROWIDs for later use because the corresponding row might either not exist or contain completely different data.

26.2.2.8.5 Application Assumes that Location Values Do Not Change

SYSCONTEXT options comprise a location-independent set such as National Language Support (NLS) settings, ISDBA, CLIENT_IDENTIFIER, MODULE, and ACTION, and a location-dependent set that uses physical locators. Typically, an application does not use the physical identifier, except in testing environments. If physical locators are used in mainline code, then the replay finds the mismatch and rejects it. However, it is acceptable to use physical locators in callbacks.

Example

select 
    sys_context('USERENV','DB_NAME') 
    ,sys_context('USERENV','HOST') 
    ,sys_context('USERENV','INSTANCE') 
    ,sys_context('USERENV','IP_ADDRESS') 
    ,sys_context('USERENV','ISDBA')  
    ,sys_context('USERENV','SESSIONID') 
    ,sys_context('USERENV','TERMINAL') 
    ,sys_context('USERENV','SID') 
from dual;

26.2.2.9 Killing or Disconnecting a Session Without Replay

If Application Continuity is configured and if a DBA kills or disconnects a session by using the ALTER SYSTEM KILL SESSION or ALTER SYSTEM DISCONNECT SESSION statement, Application Continuity by default attempts to recover the session. However, if you do not want the session to be replayed, use the NOREPLAY keyword:

alter system kill session 'sid, serial#, @inst' noreplay;
alter system disconnect session 'sid, serial#, @inst' noreplay

To kill all sessions executing on the local instance (rather that only one session) and not have the sessions replayed, you can also use the DBMS_SERVICE.DISCONNECT_SESSION PL/SQL procedure and specify NOREPLAY for the disconnect_option parameter.

See Also:

26.2.3 Mutable Objects and Application Continuity

When a request is replayed, the default and desired treatment of mutable objects can vary. A mutable object is a nondeterministic function that can obtain a new value every time it is called. An example of a mutable object use is a call to the SYSTIMESTAMP function. Client applications using Application Continuity can determine whether to keep the original value for mutable functions if the request is replayed.

Support for keeping mutable object values is currently provided for SYSDATE, SYSTIMESTAMP, SYS_GUID, and sequence.NEXTVAL. If the original values are not kept and if different values for these mutable objects are returned to the client, replay is rejected because the client sees different results. If the application can use original values, configure mutable objects using the KEEP clause for owned sequences and GRANT KEEP for other users. (Most applications need sequence values to be kept at replay, for bind variable consistency.)

Note:

Keeping SYS_GUID values is supported only for serial execution plans. When parallel query is used, Application Continuity is not able to restore original values for SYS_GUID.

Table 26-1 shows examples of the treatment of mutable objects by products during replay. (Actual implementation depends on specific products and releases.)

Table 26-1 Example Treatment of Mutable Objects by Products During Replay

Mutable Object Product 1 Product 2 Product 3

SYSDATE, SYSTIMESTAMP

Original

Original

Current

Sequence NEXTVAL and CURRVAL

Original

Original

(Not applicable)

SYS_GUID

Original

(Not applicable)

(Not applicable)

LOB access

Fail on mismatch

(Not applicable)

(Not applicable)


To allow Application Continuity to keep and use original function results at replay:

  • The database user running the application might have the KEEP DATE TIME and KEEP SYSGUID privileges granted, and the KEEP SEQUENCE object privilege on each sequence whose value is to be kept. For example:

    grant KEEP DATE TIME to user2;
    grant KEEP SYSGUID to user2;
    grant KEEP SEQUENCE on sales.seq1 to user2;
    

    Note:

    GRANT ALL ON <object> does not include (that is, does not grant the access provided by) the KEEP DATE TIME and KEEP SYSGUID privileges and the KEEP SEQUENCE object privilege.

    Grant privileges related to mutable object support only to application users, and to each application user, grant only the necessary privileges.

    Do not grant DBA privileges to database users running applications for which you want replay to be enabled.

  • Sequences in the application can use the KEEP attribute, which keeps the original values of sequence.NEXTVAL for the sequence owner, so that the keys match during replay. Most applications need sequence values to be kept at replay. The following example sets the KEEP attribute for a sequence (in this case, one owned by the user executing the statement; for others, use GRANT KEEP SEQUENCE):

    SQL> CREATE SEQUENCE my_seq KEEP;
    SQL> -- Or, if the sequence already exists but without KEEP:
    SQL> ALTER SEQUENCE my_seq KEEP;
    

    Note:

    Specifying ALTER SEQUENCE ... KEEP/NOKEEP applies to the owner of the sequence. It does not affect other users (not the owner) that have the KEEP SEQUENCE object privileges. If you want NOKEEP for all users, be sure not to grant the KEEP SEQUENCE object privilege to these users (or to revoke it from each if they have been granted it).
  • To keep function results (for named functions) at replay, the DBA must grant KEEP privileges to the user invoking the function. This security restriction ensures that it is valid for replay to save and restore function results for code that is not owned by that user.

The following additional considerations apply to granting privileges on mutable objects:

  • If a user has the KEEP privilege granted on mutable object values, then the objects inherit mutable access when the SYS_GUID, SYSDATE, and SYSTIMESTAMP functions are called.

  • If the KEEP privilege is revoked on mutable values on a sequence object, then SQL or PL/SQL blocks using that object do not allow mutable collection or application for that sequence.

  • If granted privileges are revoked between runtime and failover, then the mutable values that are collected are not applied for replay.

  • If new privileges are granted between runtime and failover, then mutable values are not collected and these values are not applied for replay.

See Also:

Oracle Database SQL Language Reference for information about the ALTER SEQUENCE and GRANT statements

26.2.4 Session State Consistency

Session state consistency describes how nontransactional state is changed during a request. Examples of session state are NLS settings, optimizer preferences, event settings, PL/SQL global variables, temporary tables, advanced queues, LOBs, and result cache. If nontransactional values change after the request starts, use the default value, Dynamic.

After a COMMIT has executed, if the state was changed in that transaction, it is not possible to replay the transaction to reestablish that state if the session is lost. Applications can be categorized depending on whether the session state after the initial setup or is static or dynamic, and hence whether it is correct to continue past a COMMIT operation.

Dynamic mode is appropriate for almost all applications. If you are unsure, use Dynamic mode. If your customers or users can modify your application, you must use Dynamic mode.

Topics:

26.2.4.1 Dynamic Session State Consistency

A session has dynamic state if the session state changes are not fully encapsulated by the initialization, and cannot be fully captured in a callback at failover. Once the first transaction completes, failover is internally disabled until the next request starts. In Dynamic session state consistency mode, state changes occur during the request and replay is enabled at the call to beginRequest.

Set the session state consistency mode to Dynamic if the nontransactional session state changes while transactions are executing. Examples of nontransactional session state that can change at runtime are ALTER SESSION, PL/SQL global variables, SYS_CONTEXT, and temporary table contents. If the application changes nontransactional state inside transactions and commits, this state cannot be replayed and the state setting must be Dynamic. When using Dynamic mode for Application Continuity, replay is disabled at COMMIT until the next request begins. Dynamic is the default value.

Figure 26-2 shows the nontransactional session state (NTSS) changes during a request when the session state consistency mode is Dynamic.

Figure 26-2 Dynamic Mode: Nontransaction State Can Change During Request

Description of Figure 26-2 follows
Description of "Figure 26-2 Dynamic Mode: Nontransaction State Can Change During Request"

As shown in Figure 26-2, replay (that is, Application Continuity) is enabled at the beginRequest call, and is disabled on a COMMIT or an endRequest call. (The use of a restricted call also disables Application Continuity, but this is not shown in the figure.) Also shown in Figure 26-2 is the step logic for three application scenarios: no transaction, a transaction with COMMIT as the last statement, and a transaction with an embedded COMMIT statement.

For the request with no transaction, the logic is as follows:

  1. Check out.

  2. Replay is disabled at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. (Other actions, indicated by a gap.)

  6. Check in.

  7. End request and disable replay.

For the request with a transaction with COMMIT as the last statement, the logic is as follows:

  1. Check out.

  2. Replay is disabled at COMMIT, at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. The transaction begins.

  6. (Other actions, indicated by a gap.)

  7. Commit (which disables replay).

  8. Check in.

  9. End request.

For the request with a transaction with an embedded COMMIT statement, the logic is as follows:

  1. Check out.

  2. Replay is disabled at COMMIT, at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. The transaction begins.

  6. (Other actions, indicated by a gap.)

  7. Commit (which disables replay).

  8. (Other actions, indicated by a gap during which Application Continuity is not covering the application.)

  9. Check in.

  10. End request.

26.2.4.2 Static Session State Consistency

Set the session state consistency mode to Static if all nontransactional state changes, such as NLS settings, SYS_CONTEXT, PL/SQL variables, and optimizer preferences, are set as part of the initialization once per request, and if this session state does not change during transactions. The settings can be established once per connection at connection establishment with UCP labeling, for example, or at each checkout from a pool. These settings must be repeated in the replay callback. When using Static mode for Application Continuity, transactional failover continues beyond the first transaction of a request.

Static mode is not supported for applications that use calls that change nontransactional state in requests. Specific examples of such calls include:

  • PL/SQL subprograms

  • SYS_CONTEXT

  • Hints

  • DDL operations

  • Autocommit

  • ALTER SESSION

  • ALTER SYSTEM

Specify static mode with caution. Use static mode only when the application does not change the NTSS (nontransactional session state) inside transactions. Declaring the session state consistency mode as Static indicates that it is safe to continue beyond the first COMMIT in a request. Dynamic mode is appropriate for most applications. Do not use static mode if users or customers can modify or customize the application.

Figure 26-3 shows the NTSS (nontransactional session state) remaining constant (that is, not changing) during a request when the session state consistency mode is Static.

Figure 26-3 Static Mode: Nontransactional State Never Changes During Request

Description of Figure 26-3 follows
Description of "Figure 26-3 Static Mode: Nontransactional State Never Changes During Request"

As shown in Figure 26-3, replay (that is, Application Continuity) is enabled at the beginRequest call, and is disabled on a restricted call or on a disableReplay or endRequest call. Also shown in Figure 26-3 is the step logic for three application scenarios: no transaction, one or more transactions each ending with COMMIT as the last statement, and a transaction with a COMMIT statement followed by a transaction with a restricted call that disables Application Continuity.

For the request with no transaction, the logic is as follows:

  1. Check out.

  2. Replay is disabled at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. (Other actions, indicated by a gap.)

  6. Check in.

  7. End request and disable replay.

For the request with one or more transactions (each with COMMIT as the last statement), the logic is as follows:

  1. Check out.

  2. Replay is disabled at COMMIT, at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. The transaction begins.

  6. The transaction commits.

  7. The transaction is purged.

  8. (For each additional transaction, steps 4 through 7 occur.)

  9. (Other actions, indicated by a gap.)

  10. Check in.

  11. End request.

For the request with a transaction with a COMMIT followed by a transaction with a restricted call, the logic is as follows:

  1. Check out.

  2. Replay is disabled at COMMIT, at endRequest, at a restricted call, and for an explicit disableReplay call.

  3. Begin request and enable replay.

  4. Issue one or more SELECT statements and perhaps other PL/SQL statements.

  5. The transaction begins.

  6. The transaction commits.

  7. The transaction is purged.

  8. The second transaction begins.

  9. The transaction makes a restricted call, which causes Application Continuity to be disabled.

  10. The transaction is purged.

  11. (Other actions, indicated by a gap.)

  12. Check in.

  13. End request.

26.3 Potential Side Effects of Application Continuity

When a session is rebuilt, all states are rebuilt. This includes reexecuting statements that leave side effects. These side effects might be exactly what is required, such as writing a report or completing some auditing. However, the actions that are replayed to build the state might include some for which you want to take action to accommodate or mitigate the effects of the replay.

Application Continuity replays PL/SQL chronologically to restore database state. This serves to rebuild the session as if the user submission was delayed. Most applications want the full state rebuilt as if the submission was repeated, such as writing a report or completing some auditing. However, the actions that are replayed to build the state might include some for which you want to take action to accommodate or mitigate the effects of the replay. Some applications elect to use the disableReplay API for requests that contain calls that they do not want to repeat.

If requests have external actions that use a messaging mechanism (such as UTL_SMTP, UTL_HTTP, or UTL_FILE), then review the requests to decide if they must be replayed.

Examples of actions that create side effects include the following:

  • Autonomous transactions (independent transactions that can be called from other transactions, as explained in Section 6.7, "Autonomous Transactions")

  • DBMS_ALERT calls (email or other notifications)

  • DBMS_FILE_TRANSFER calls (copying files)

  • DBMS_PIPE and RPC calls (to external sources)

  • UTL_FILE calls (writing text files)

  • UTL_HTTP calls (making HTTP callouts)

  • UTL_MAIL calls (sending email)

  • UTL_SMTP calls (sending SMTP messages)

  • UTL_TCP calls (sending TCP messages)

  • UTL_URL calls (accessing URLs)

See Also:

Disabling Replay in Application Continuity for Java for information about disabling replay and for related considerations

26.4 Restrictions and Other Considerations for Application Continuity

The following restrictions and other considerations apply to Application Continuity for Java:

  • It applies only to JDBC Thin connections (JDBC OCI is not supported).

  • For applications using JDBC, there is no support for oracle.sql deprecated concrete classes: BLOB, CLOB, BFILE, OPAQUE, ARRAY, STRUCT, or ORADATA. (See My Oracle Support Note 1364193.1, New Jdbc Interfaces for Oracle types: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1)

  • For JDBC streams arguments, replay is on a "best effort" basis. For example, if the application is using physical addresses, the address has gone with the outage and cannot be repositioned. JDBC stream setters (such as setBinaryStream), for example, cause replay to be disabled.

  • The replay target database must have the same database ID, pluggable database ID, ancestors, and descendants as the source database.

    Application Continuity does not replay if the target is a different database or if it is the same database or same pluggable database but with data loss, such as one flashed back, recovered incompletely by media recovery, or opened by Oracle Data Guard earlier in time.

  • Replay is not supported for applications developed using Oracle XA.

  • Replay is disabled if a request issues an ALTER SYSTEM or ALTER DATABASE statement.

  • Replay is not supported if you are using Active Data Guard with read/write database links to another database.

Note:

If you are creating clones of databases by splitting disk images (for example, BCVs) or by cloning so it is a "different" database to make a logical standby or logical copy that is not a physical or Active Data Guard database, nid must be used to change the DBID to differentiate the databases. For information about nid program usage, see these My Oracle Support notes: How to Change the DBID and the DBNAME by using NID (Doc Id 224266.1) and Changing DBNAME and DBID of Oracle RAC Database Using NID (Doc Id 464922.1).