You can use the srvctl start service command to start all services on a node, all services offered by a database, all services offered by a pluggable database, or all services offered on an instance or within a given server pool.

• To start all of the services offered by a single pluggable database:

  $ srvctl start service –db myRACCDB01 –pdb myPDB01 –startoption OPEN

  To start all services on a given database and any of its pluggable databases:

  $ srvctl start service –db myRACDB

  To start a list of services on a given database, regardless of any pluggable database with which they are associated:

  $ srvctl start service –db myRACDB –service "myFirstService,mySecondService,myThirdService"

  To start all services for a database that can run on a given node:

  $ srvctl start service –d myRACDB –node racnode01

You can use SRVCTL to manage services on pluggable databases.

• To start all services for a pluggable database, for all instances or a single instance:

  $ srvctl start service -db db_name -pdb pdb_name [-instance instance_name]

• To stop all services for a pluggable database, for all instances or a single instance:

  $ srvctl stop service -db db_name -pdb pdb_name [-node node_name | -instance 
     inst_name | -serverpool pool_name] [-stopoption stop_option] [-drain_timeout timeout]
     [-force [-noreplay]]

  Note:

  The -pdb pdb_name parameter is optional. If you omit the pluggable database name, then the operation occurs for the entire container database (all pluggable databases within this container).

You can use the srvctl relocate service command to relocate services to a target destination, which can be an instance, a node, or a database.

$ srvctl relocate service –db myRACCDB –oldinst RACCDB_01 –newinst RACCDB_03
  -drain_timeout 30 -stopoption immediate

$ srvctl relocate service –db myRACCDB –pdb myPDB01 –currentnode racnode01
  –targetnode racnode02 -drain_timeout 30 -stopoption immediate

$ srvctl relocate service –db myRACCDB –service "myService01,myService02"
  -drain_timeout 30 -stopoption immediate

$ srvctl relocate service –db myRACCDB –pdb myPDB01 -drain_timeout 30
  -stopoption transactional

You can use the srvctl stop service command to stop all services on a node, all services offered by a database, all services offered by a pluggable database, or all services offered on an instance or within a given server pool.

• To stop all of the services offered by a single pluggable database:

  $ srvctl stop service –db myRACCDB01 –pdb myPDB01 –drain_timeout 15 –stopoption TRANSACTIONAL

  To stop all services on a given database and any of its pluggable databases:

  $ srvctl stop service –db myRACDB –drain_timeout 15 –stopoption IMMEDIATE

  To stop only a subset of the services offered by a database:

  $ srvctl stop service –db myRACDB –service "myFirstService,mySecondService,
    myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

  Note:

  If you use the –wait YES SRVCTL command line parameter, then the –stopoption parameter is not enforced until the entire drain timeout interval has expired, even if all of the sessions have exited prior to this interval completing.

Transparent Application Continuity is a functional mode of Application Continuity introduced with Oracle Real Application Clusters (Oracle RAC) in Oracle Database release 18c that transparently tracks and records session and transactional state so that a database session can be recovered following recoverable outages.

Recovery of the user database session is done safely and with no need for a DBA 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 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 where to fail the database session over and invokes 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.

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.

When you use Transparent Application Continuity with Java (beginning with Oracle Database 18c) and OCI and ODP.NET Unmanaged Provider (beginning with Oracle Database 19c release 19.3), your applications will experience lower resource usage and faster recovery because statements that do not contribute to the state are not recorded, or they are purged when no longer needed, and request boundaries are advanced automatically.

Transparent Application Continuity covers applications that belong to three different groups, automatically tracked by the state tracking system.

Support for Application Continuity is integrated into many Oracle applications.

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

• ODP.NET, Unmanaged Driver 12.2 or later
• OCI Session Pool 12.2 and later
• Universal Connection Pool 12.1 or later
• Oracle WebLogic Server 12c
• JDBC Thin Oracle replay driver 12.1 or later
• Java connection pools or standalone Java applications using Oracle JDBC -Replay Driver 12c or later with Request Boundaries
• SQL*Plus 19.3 or later
• Third-party JDBC application servers with Universal Connection Pool

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

• Oracle Call Interface (OCI) and Oracle C++ Call Interface (OCCI)
• ODP.NET, Unmanaged Driver 12.2 or later
• Oracle Tuxedo 19.3 or later
• OCI Session Pool 12.2 and later
• SQL*Plus 19.3 or later
• Oracle JDBC OCI driver (thick driver is not recommended in genera

Application Continuity for Java is embedded in the Universal Connection Pool, WebLogic data sources, including non-XA and XA data sources, and is available with the thin JDBC replay driver, standalone (which is a JDBC replay driver without Oracle connection pools, such as Apache Tomcat or a custom Java connection pool). Application Continuity for OCI is embedded in SQL*Plus, OCI Session Pool 12.2 or later, and ODP.NET, Unmanaged Provider. With Transparent Application Continuity, JDBC applications auto enable starting with Oracle Database 18c, and OCI applications starting with Oracle Database 19c (19.3).

If a connection pool or container does not use an Oracle connection pool, then many third-party Java applications fully support replacing the connection pool with the Universal Connection Pool. This includes IBM WebSphere and Apache Tomcat. Alternatively—for Java applications, only—an application can add its own request boundaries.

The Application Continuity features in various Oracle applications are used automatically if you set the required service attributes.

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.

The main actions for ensuring transparent replay for an application are the following:

1. Only if using Java, determine whether the application uses Oracle JDBC concrete classes. For Application Continuity to be used, the deprecated concrete classes must be replaced.

   Use the -acchk parameter with the ORAchk utility to verify whether an application has any concrete classes. Use a connection without Application Continuity if there is anything that should not be replayed. (Most applications will be replayable.)

   See Also:

   Oracle Autonomous Health Framework User's Guide for more information about ORAchk

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

   • CPU: Application Continuity is managed on the client and server sides and requires minimal CPU overhead 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: When using Application Continuity, 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 client. 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 connection pool, for example WebLogic Server Pool, Universal Connection Pool, OCI Session Pool, Oracle Tuxedo request, or ODP.NET connection pool, for each request, or whether to add beginRequest and endRequest APIs to the application's own connection pool to identify request boundaries for Java, only.

   Important:

   Do not use the beginRequest and endRequest Java API calls anywhere other than at request boundaries (borrow and return connections from your connection pool). 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 using FAILOVER_RESTORE or callback.

4. Application Continuity replays all states in a request. If the application sets states before vending connections, FAILOVER_RESTORE or a callback is needed. When using Oracle WebLogic Server or the Universal Connection Pool, use FAILOVER_RESTORE, connection labeling, or triggers. When using OCI session pool, Oracle Tuxedo or ODP.NET with Oracle Database 18c, or later clients, use FAILOVER_RESTORE, and only add the TAF callback if it is needed. 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.

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

   • If session_state_consistency is set to AUTO, then Transparent Application Continuity monitors the session state and decides what to do. If you are unsure about state usage or know that states can change in the future, then use Transparent Application Continuity. See the list of preset session states because you may need to restore additional preset states.

   • If session_state_consistency is set to DYNAMIC, then the application changes the environment or settings during the request. Replay is disabled after the first COMMIT until the beginning of the next request. DYNAMIC is the default mode, appropriate for most applications.

   • If session_state_consistency is set to STATIC, then 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 Transparent Application Continuity with session_state_consistency set to AUTO instead of STATIC. The AUTO setting verifies that the session state is static.

7. Determine if any requests in the application should not be replayed.

   For example, replay may need to be disabled for requests using external PL/SQL actions.

8. Follow these configuration guidelines:

   • Use Oracle Database 12c release 1 (12.1.0.1), or later, for Java. Use Oracle Database 12c release 2 (12.2), or later, for OCI-based applications.

   • For .NET applications, use ODP.NET, Unmanaged Driver 12.2, or later, connecting to an Oracle Database 12c Release 2 (12.2) or later. By default, Application Continuity is enabled for ODP.NET applications in this configuration. When using OCI-based applications that do not use the OCI Session Pool, including SQL*Plus, use Transparent Application Continuity that adds boundaries for you.

   • For Java-based applications, use Universal Connection Pool 12.1 (or later) or WebLogic Server 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. For IBM WebSphere, Apache Tomcat, RedHat Spring, and custom Java solutions, the most effective solution is to use UCP as the pooled data source.

     Custom Java pools and standalone Java applications can also use the JDBC Replay data source directly. When using custom Java pools and standalone applications, Oracle recommends that you use Transparent Application Continuity which adds boundaries for you. You can also add beginRequest and endRequest Java API's to your application.

   • If the application does not borrow and return from the Oracle connection pools, explicitly mark request boundaries. For example, if using custom JDBC pools, or other pools, Oracle recommends that you use Transparent Application Continuity which adds boundaries for you. You can also add beginRequest and endRequest Java API's to your application. These APIs can also be used for standalone JDBC applications without a connection pool.

   • Enable FAN for fast interrupt on errors. This is essential to eliminate a TCP hang occurring before the failover can start. In 12.2 FAN is built into the JDBC and OCI drivers and is on by default for Java.

   • Use a database service to connect; never use a SID or an instance name, or the administration service that is the DB_NAME or DB_UNIQUE_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 for the manual mode of Application Continuity or set FAILOVER_TYPE to AUTO for Transparent Application Continuity. Set COMMIT_OUTCOME to TRUE and, for OCI FAN, set NOTIFICATION to TRUE. Optionally to find the best connections to use, set GOAL to SERVICE_TIME and CLB_GOAL to LONG.

   • Use the statistics for request boundaries and protection level to monitor the level of coverage. If you need more details, then use Application Continuity Check Coverage (with the ORAchk utility) to report the percentage of requests that are fully protected by Application Continuity, and the location of those requests that are not fully protected. Use this coverage check before deployment and after application changes. Developers and management will know how well protected an application release is from failures of the underlying infrastructure. If there is a problem, then it can be fixed before the application is released, or waived knowing the level of coverage.

These are general recommendations for configuring the connections used by applications for high availability.

If you are using Java, then you must use the oracle.jdbc.replay.OracleDataSourceImpl, oracle.jdbc.replay.OracleConnectionPoolDataSourceImpl, or oracle.jdbc.replay.driver.OracleXADataSourceImpl data source to obtain JDBC connections. These data sources support all the properties and configuration parameters of all the Oracle JDBC data sources, for example, the oracle.jdbc.pool.OracleDataSource.

For OCI based applications including SQL*Plus and ODP.NET, the OCI driver 12.2, and later, supports Application Continuity.

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 the connect string uses the SCAN Name, then REMOTE_LISTENER must be set to the SCAN name.
  • If the connect string uses an ADDRESS_LIST of host VIPs, then REMOTE_LISTENER must be set to an address list that includes all SCAN VIPs and all host VIPs

  Note:

  Use SCAN for location independence, to avoid having to reconfigure the client when you add or delete nodes, or when databases change to running on different nodes.

• Set RETRY_COUNT, RETRY_DELAY, CONNECT_TIMEOUT, and TRANSPORT_CONNECT_TIMEOUT parameters in the connection string. 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 applies per address.

• Set CONNECT_TIMEOUT to a high value to prevent an overabundance of log ins. Low values can result in log in storms to the application or server pool canceling and retrying. Do not set (RETRY_COUNT+1)*RETRY_DELAY or CONNECT_TIMEOUT larger than your response time SLA. The application must either connect or receive an error within the response time SLA.

• Starting with Oracle Database release 19c you can use Easy Connect syntax, as it has high availability capabilities. For example:

  primary-vip,secondary-vip:1521/sales.example.com?connect_timeout=90&transport_connect_timeout
  =3&retry_count=30&retry_delay=3

myAlias=(DESCRIPTION= 
   (CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=RAC-scan)(PORT=1521)))
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=DG-Scan)(PORT=1521)))
   (CONNECT_DATA=(SERVICE_NAME=service_name))

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

• If you are using Oracle Real Application Clusters (Oracle RAC) or Oracle RAC One Node, Oracle Data Guard, or Oracle Active Data Guard, then ensure that FAN is configured with Oracle Notification Service (ONS) to communicate with Oracle Database 12c pools and drivers.

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

  • FAILOVER_TYPE = AUTO | TRANSACTION: Use FAILOVER_TYPE=AUTO for Transparent Application Continuity or FAILOVER_TYPE=TRANSACTION for manual Application Continuity. This attribute enables the replay functionality for the replay drivers and Application Continuity. Oracle drivers keep track of all replayable statements issued during a database session. If all of the statements are replayable, and any in-flight transactions did not commit or the session is in conversation, then Oracle replays the uncommitted work following a planned or unplanned database outage. This mode re-establishes transactional and non-transaction states automatically with no additional application steps.

  • REPLAY_INITIATION_TIMEOUT = n: For setting the duration, in seconds, to allow replay to start (where the value of n can 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 Global Data Services, then this is a recommended setting

  • CLB_GOAL = SHORT: If you are using Oracle RAC or Oracle Global Data Services, then this is a recommended setting

  • COMMIT_OUTCOME = TRUE: For using Transaction Guard

  • FAILOVER_RESTORE = AUTO | LEVEL1: Use FAILOVER_RESTORE=AUTO for Transparent Application Continuity and FAILOVER_RESTORE=LEVEL1 for manual Application Continuity. To automatically restore client states that are preset on the connection pool before replay begins—including AUTOCOMMIT state (for Java and SQL*Plus), NLS states, and TAGS (MODULE, ACTION, ECID, CLIENT_ID, CLIENT_INFO) states.

• Grant permission on the Application Continuity package, DBMS_APP_CONT, to the database users that fail over using Application Continuity, as follows:

  GRANT EXECUTE ON DBMS_APP_CONT TO user_name;

• Do not use the default database service corresponding to the DB_NAME or DB_UNIQUE_NAME. Also, do not use the default database service for high availability, because this service cannot be enabled or disabled, and cannot be relocated on Oracle RAC or switched over to Oracle Data Guard. This service is reserved for Oracle Enterprise Manager Cloud Control (Cloud Control) and for DBAs.

Some applications set an initial state for the connection before allowing applications to use the connection.

Examples of states that can be preset include:

• PL/SQL package state
• NLS Setting
• Optimizer setting

During a request, Application Continuity reestablishes the entire state for the request. This prerequisite is for the initial state before Application Continuity starts replaying.

A callback is not required if FAILOVER_RESTORE restores all required states, which is the case for most applications.

The topics in this section apply to 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.

• FAILOVER_RESTORE

• States Restored with FAILOVER_RESTORE
• FAILOVER_RESTORE Extended
• Configuring a Keystore for FAILOVER_RESTORE
• Configuring a Wallet and SQLNET.ORA for FAILOVER_RESTORE

• FAILOVER_RESTORE = NONE and No Callback

• Connection Labeling

• Connection Initialization Callback

By default, when Application Continuity 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 connecting and 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.

The following examples show various failover scenarios:

• Creating Services on Oracle RAC with Application Continuity

• Modifying Services on Single-instance Databases to use Application Continuity

For planned maintenance, 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.

To use Application Continuity for planned maintenance:

1. Use any FAN-aware pool, such as OCI, UCP, WebLogic Server, or ODP.NET Managed and Unmanaged Drivers.

   The FAN planned event drains at request boundaries.

   Note:

   ODP.NET Managed Driver does not support Application Continuity.

2. Use the srvctl relocate service command to relocate the service from the instance without disrupting the sessions or, for a uniform service, use the srvctl stop service command on the instance (do not use the -force parameter).

   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, then stop the instance (abort).

   For Application Continuity-enabled pools (UCP, WebLogic, Tuxedo, ODP.NET, and OCI), and any Java pool that adds beginRequest/endRequest , 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.

Sometimes Application Continuity is not in effect because a disabling call has been issued.

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 to the endRequest call.

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

Application Continuity is disabled for the current request when any of the following occurs:

• The application runs a statement that is restricted for Application Continuity (for example, ALTER SYSTEM).

• Application Continuity is explicitly disabled using disableReplay.

• A COMMIT statement is issued when the service parameter session_state_consistency is set to Dynamic (the default, when not using Transparent Application Continuity).

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

• The session is terminated or disconnected and the NOREPLAY keyword is specified.

Replay occurs following a recoverable error but you can disable replay.

If an application has requests that the application does not want repeated, then the application can take a connection to a service that does not have Application Continuity enabled, or can explicitly call an API to disable replay for those requests. If you use Transparent Application Continuity, then side effects are detected and disabled automatically. You do not need to understand the application or to disable requests with side effects.

When using manual Application Continuity all calls are replayed. If an application uses UTL_SMTP, for example, and does not want messages repeated, then the application could use a connection to a different service, or use the disableReplay API on Java, or OCIRequestDisableReplay API for OCI. 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 rules are generic. They apply to all applications that replay work, including Application Continuity, and TAF (release 12.2 and after).

• Application Calls Autonomous Transactions, External PL/SQL, or Java Actions that Should Not Be Repeated

• Application Synchronizes Independent Sessions

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

• Application Assumes that ROWIds Do Not Change

• Application Assumes that Location Values Do Not Change

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

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

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

$ srvctl stop service -db orcl -instance orcl2 –drain_timeout 60 -stopoption immediate -force -noreplay

$ srvctl stop service -db orcl -node myode3 –noreplay -drain_timeout 60 -stopoption immediate -force

$ srvctl stop instance -node mynode3 -drain_timeout 60 -stopoption immediate -force –noreplay

To terminate all sessions running 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.

To keep function results at replay, you must grant KEEP privileges to the user invoking the function.

• To grant permission to keep mutables for SYSDATE and SYSTIMESTAMP, or SYSGUID:

  GRANT [KEEP DATE TIME | KEEP SYSGUID]...[to USER]

  For example, for possible Oracle E-Business Suite usage with original dates:

  GRANT KEEP DATE TIME, KEEP SYSGUID to [custom user];
  GRANT KEEP DATE TIME, KEEP SYSGUID to [apps user];

• To revoke permission to keep mutables for SYSDATE and SYSTIMESTAMP, or SYSGUID:

  REVOKE [KEEP DATE TIME | KEEP SYSGUID]...[from USER]

To keep the original values of sequence.nextval for replaying so that keys match, you must grant permissions on the sequence.

• To grant permission as the owner of the sequence:

  CREATE SEQUENCE [sequence object] [KEEP|NOKEEP];
  ALTER SEQUENCE [sequence object] [KEEP|NOKEEP];
  

• To grant and revoke permission for others using the sequence:

  GRANT KEEP SEQUENCE...[to USER] on [sequence object];
  REVOKE KEEP SEQUENCE...[from USER] on [sequence object];

  For example, for possible Oracle E-Business Suite usage with original sequence values:

  GRANT KEEP SEQUENCE to [apps user] on [sequence object];
  GRANT KEEP SEQUENCE to [custom user] on [sequence object];

These considerations apply to granting and revoking privileges on mutable functions.

• If you grant all on an object for a user, then mutables are excluded. Mutables require explicit grants. Oracle does not support granting mutables to the users supplied or created by Oracle Database, such as SYS, AUDSYS, GSMUSER, and SYSTEM.

• The DBA role includes mutable permission.

• If a user has mutables granted, then the objects inherit mutable access when the mutable functions are called (in SYS_GUID, SYSDATE and SYSTIMESTAMP).

• If keeping mutables on a sequence object is revoked, then SQL or PL/SQL commands using that object does not allow mutable collection or application for that sequence.

• If grants are revoked between run time and failover, then the mutables that were collected are not applied.

• If grants are granted between run time and failover, then mutables are not collected and so none are applied.

When you set session_state_consistency to AUTO, Transparent Application Continuity tracks and records session and transactional states so the database session can be recovered following recoverable outages. Setting session_state_consistency to AUTO is the only value permitted for Transparent Application Continuity.

When set to AUTO, a state-tracking infrastructure categorizes session state usage as the application issues user calls. Tracked session states are monitored and verified.

A session has dynamic state if the session state values are not fully restored by FAILOVER_RESTORE, or by adding the initialization callback.

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 beginning of the next request.

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.

The nontransactional session state (NTSS) changes during a request when the session state consistency mode is Dynamic.

For the request with no transaction, the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. Other actions.

5. Check in.

6. End request and disable replay.

For the request with a transaction with COMMIT as the last statement, the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. The transaction begins.

5. Other actions.

6. Commit (which disables replay).

7. Check in.

8. End request.

For the request with a transaction with an embedded COMMIT statement, the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. The transaction begins.

5. Other actions.

6. Commit (which disables replay).

7. Other actions, during which Application Continuity is not covering the application.

8. Check in.

9. End request.

Static mode is used for long running stateless applications. Do not use Static mode for applications that are not stateless.

Set the session state consistency mode to Static, only if all non-transactional 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 when using FAILOVER_RESTORE=LEVEL1, a callback, or labels, for example, or at each checkout from a pool.

When using Static mode for Application Continuity, transactional failover continues beyond the first transaction of a request. This is useful for applications that set beginRequest once and run long processing operations such as batch jobs, and long reports.

Static mode is not supported for applications that use calls that change non-transactional state in transactions. Specific examples of such calls include:

• PL/SQL subprograms

• SYS_CONTEXT

• ALTER SESSION

Specify static mode with caution. Use static mode only when the application does not change the non-transactional 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.

The non-transactional session state remaining constant (that is, not changing) during a request when the session state consistency mode is Static.

Replay (that is, Application Continuity) is enabled at the beginRequest call, and is disabled on a restricted call, on a disableReplay or OCIRequestDisableReplay call, or on an endRequest call.

For the request with no transaction, the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. Other actions.

5. Check in.

6. End request and disable replay.

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

For the request with one or more transactions (each with COMMIT as the last statement), the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. The transaction begins.

5. The transaction commits.

6. The transaction is purged.

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

7. Other actions.

8. Check in.

9. End request.

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

For the request with a transaction with a COMMIT followed by a transaction with a restricted call, the logical steps are as follows:

1. Check out.

2. Begin request and enable replay.

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

4. The transaction begins.

5. The transaction commits.

6. The transaction is purged.

7. The second transaction begins.

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

9. The transaction is purged.

10. Other actions

11. Check in.

12. End request.

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