1. Real Application Clusters Administration and Deployment Guide
  2. Administering Application Continuity Operation and Usage

Administering Application Continuity Operation and Usage

Learn how to manage the use of Application Continuity, and how you can use it in applications.

Using Application Continuity for Planned Maintenance

For planned maintenance, Oracle recommends that you drain requests from Oracle connection pools in combination with Application Continuity for those requests that do not complete.

This procedure has the least impact when there is minimal recovery to complete. Instances do need to be stopped to switch over to the patched software.

  1. 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.
    • Oracle Data
      Provider for .NET (ODP.NET), Unmanaged Driver is deprecated in Oracle AI
      Database 26ai.
  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 (terminate).

    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.

Related Topics

Administering Restoring Original Function Results

Application Continuity handles mutable values in top-level SQL automatically starting with Oracle Database 19c. Starting with Oracle AI Database 26ai, this automatic handling also applies to anonymous PL/SQL. Use the following grant and revoke procedures only for cases that require explicit KEEP privileges.

Restoring Original Oracle Function Values and Application Continuity

Mutable functions can return a different value each time they are called. During replay, Application Continuity preserves the original values of supported functions and sequences so that the application receives consistent results. Supported values include SYSDATE, SYSTIMESTAMP, CURRENT_TIMESTAMP, LOCALTIMESTAMP, SYS_GUID, and sequence.NEXTVAL.

Starting with Oracle Database 19c, Application Continuity handles mutable values used in top-level SQL automatically, including SQL statements such as SELECT. You do not need to grant KEEP privileges or use the KEEP clause for an owned sequence for these calls.

Starting with Oracle AI Database 26ai, this automatic handling also applies to anonymous PL/SQL. You do not need to grant KEEP privileges or use the KEEP clause for mutable values used in top-level SQL or anonymous PL/SQL.

Keeping SYS_GUID values is supported only for serial processing plans. When parallel query is used, Application Continuity cannot restore original SYS_GUID values.

Notes:

  • Starting with Oracle Database 19c, grants are not required for keeping mutable values used in SQL, including sequence values.
  • GRANT ALL ON object does not include the KEEP DATE TIME and KEEP SYSGUID privileges or the KEEP SEQUENCE object privilege.
  • Grant privileges related to restoring original Oracle function values only to application users. Grant each application user only the privileges needed.
  • Do not grant DBA privileges to database users running applications for which replay is enabled.

Related Topics

Checking Your Keep Permissions

You must ensure that you have required KEEP permissions to keep function results at replay.

  • To check permission to keep SYSDATE and SYSGUID:

    SELECT * FROM USER_SYS_PRIVS WHERE PRIVILEGE LIKE '%KEEP%';

    This query returns output similar to the following:

    USERNAME   PRIVILEGE        ADM   COM   INH
--------   --------------   ---   ---   ---
SOE1       KEEP SYSGUID     NO    NO    NO
SOE1       KEEP DATE TIME   NO    NO    NO
  • To check permission to keep SEQUENCES: 
    SELECT SEQUENCE_NAME, KEEP_VALUE FROM USER_SEQUENCES;

    This query returns output similar to the following:

    SEQUENCE_NAME   KEEP_VALUE
-------------   ----------
SEQ_PERSON      N      
SEQ_PLSQL       N
SEQ_PRODUCTS    Y
SEQ_PRODUCT_ID  Y

    The KEEP_VALUE in the above example is Y or N.

    Note:

    For all sequences grants, run the SELECT SEQUENCE_NAME, KEEP_VALUE FROM ALL_SEQUENCES; statement.

Granting and Revoking Keep Permissions for Restoring Original Oracle Function Values

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

  • To grant permission to keep restoring original Oracle function values 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 restoring original Oracle function values for SYSDATE and SYSTIMESTAMP, or SYSGUID:

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

Granting Permission to Keep Restoring Original Oracle Function Values for Oracle Sequences

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 on sequence.object to [myUser|role];
REVOKE KEEP SEQUENCE on sequence.object from [myUser|role];

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

    GRANT KEEP SEQUENCE on sequence.object to apps-user;
REVOKE KEEP SEQUENCE on sequence.object from my-user ;

    For example, for identity sequences, use the KEEP clause on the table create or alter statements:

    CREATE TABLE tab_identity_mine(id NUMBER GENERATED ALWAYS AS IDENTITY keep, 
content varchar2(50));

Rules for Grants on Restoring Original Oracle Function Values

These considerations apply to granting and revoking privileges on restoring original Oracle function values.

  • If you grant all on an object for a user, then restoring original Oracle function values are excluded. Restoring original Oracle function values require explicit grants. Oracle does not support granting restoring original Oracle function values to the users supplied or created by Oracle AI Database, such as SYS, AUDSYS, GSMUSER, and SYSTEM.
  • The DBA role includes restoring original Oracle function value permission.
  • If a user has restoring original Oracle function values granted, then the objects inherit restoring original Oracle function value access when the functions are called (in SYS_GUID, SYSDATE and SYSTIMESTAMP ).
  • If keeping restoring original Oracle function values on a sequence object is revoked, then SQL or PL/SQL commands using that object does not allow restoring original Oracle function value collection or application for that sequence.
  • If grants are revoked between run time and failover, then the restoring original Oracle function values that were collected are not applied.
  • If grants are granted between run time and failover, then restoring original Oracle function values are not collected and so none are applied.

Protection-Level Statistics

Use the statistics for request boundaries and protection level to monitor the level of coverage.

Application Continuity collects statistics from the system, the session, and the service, enabling you to monitor your protection levels. The statistics are available in V$SESSTAT, V$SYSSTAT, and, when service statistics are enabled, in V$SERVICE_STATS. For example, if you query V$SESSTAT and join with V$STATNAME, you can view output like the following:

NAME                                                             VALUE
---------------------------------------------------------------- ----------
cumulative begin requests                                               731
cumulative end requests                                                 739
cumulative user calls in requests                                      7285
cumulative user calls protected by Application Continuity              7228
cumulative time in requests                                      2665167909

These statistics are saved in the Automatic Workload Repository (AWR) and are available in AWR reports. Statistics include:

  • Requests completed per second
  • User calls in a request
  • Protected user calls

The AWR report output is similar to the following:

Statistic                                Total    per Second    per Trans
---------------------------------------- -------- ------------- ---------
cumulative requests                       177,406          49.2       5.0
cumulative user calls in request          493,329         136.8      13.8
cumulative user calls protected           493,329         136.8      13.8

To enable protection-level statistics, use (_request_boundaries = 3).

Session State Consistency

Session state consistency describes how non-transactional state is changed during a request.

About Session State Consistency

To ensure session state consistency, Oracle recommends that you set the service parameter session_state to AUTO, which is available with Transparent Application Continuity.

Transparent Application Continuity tracks and manages session states. If you choose to use Transparent Application Continuity, then you do not have to do anything else to ensure session state consistency.

You can set session_state to DYNAMIC for Application Continuity. You should only set session_state to DYNAMIC if you fully understand the application, and the application is not expected to change from the value set.

Examples of session state are NLS settings (globalization support), optimizer preferences, event settings, PL/SQL global variables, temporary tables, advanced queues, Large Objects (LOBs), and result cache. If non-transactional values change in committed transactions, then use the default value, DYNAMIC.

Using DYNAMIC mode, after a COMMIT has run, if the state was changed in that transaction, then 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 is dynamic, and hence whether it is correct to continue past a COMMIT operation.

AUTO mode is appropriate for almost all applications. If your customers or users can modify your application, then you must use AUTO or DYNAMIC mode. AUTO mode is a newer version of DYNAMIC mode with the additional feature that it re-enables automatically when possible.

Note:

Set session_state to AUTO for long-running, stateless applications. Unless you require Application Continuity, Oracle recommends setting session_state to AUTO.

Auto Session State Consistency

When you set the service parameter session_state 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 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.

Note:

If you set session_state to AUTO, then you must also set failovertype to AUTO.

Replay (that is, Transparent Application Continuity) is enabled at an explicit begin request (from an Oracle pool, which is the usual source, or added by OCI or JDBC thin APIs), and is disabled on a COMMIT, at the end of a request (most often return to the pool), or a restricted call. Transparent Application Continuity automatically re-enables replay when the session state is describable after a disable within a request. Following is the step logic for three application scenarios:

  • No transaction
  • A transaction with COMMIT as the last statement
  • A transaction with an embedded COMMIT statement

Note:

Enable RESET_STATE if the session state set should not leak to the next request. This also ensures that TAC is enabled in the next request when PL/SQL is used.

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

  1. Check out from a connection pool.
  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.

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

  1. Check out from a connection pool.
  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 from a connection pool.
  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 (inside PL/SQL).
  7. Next SQL statement, which re-enables Transparent Application Continuity when possible.
  8. Check in.
  9. End request.

Dynamic Session State Consistency

Application Continuity uses Dynamic Session State Consistency. The session state is tracked as it is for TAC when using Session State Consistency = AUTO.

Replay (that is, Application Continuity) is enabled at the beginRequest call, and is disabled on a COMMIT , an endRequest call, or a restricted call. Following is the step logic for three application scenarios:

  • No transaction
  • A transaction with COMMIT as the last statement
  • A transaction with an embedded COMMIT statement

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

  1. Check out from a connection pool.
  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 from a connection pool.
  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 from a connection pool.
  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.

Application Continuity Statistics

Once Application Continuity is configured, you can use the statistics to verify Application Continuity usage and to check how well Application Continuity is protecting user workloads.

You can read the following statistics from the V$SESSTATS and V$SYSSTAT views:

  • cumulative begin requests
  • cumulative end requests
  • cumulative user calls in requests
  • cumulative user calls protected by Application Continuity
  • cumulative time in requests

You can read the following statistics only from the V$SESSTATS view:

  • cumulative DB time in requests
  • cumulative DB time protected in requests
  • successful replays by Application Continuity
  • rejected replays by Application Continuity

The following example shows you how to read Application Continuity statistics values for each active session.

SQL> SELECT sn.name, s.value FROM V$SESSTAT s, V$STATNAME sn WHERE sn.statistic# = s.statistic# AND sn.name in(
    'cumulative begin requests','cumulative end requests','cumulative user calls in requests','cumulative user calls protected by Application
    Continuity','cumulative time in requests');

The following example shows you how to read Application Continuity statistics from the V$SYSSTAT view.

SQL> SELECT name, value FROM V$SYSSTAT WHERE name in ('cumulative begin requests','cumulative end requests',
    'cumulative user calls in requests','cumulative user calls protected by Application Continuity','cumulative time in requests',
    'cumulative DB time in requests','cumulative DB time protected in requests','successful replays by Application Continuity',
    'rejected replays by Application Continuity');

Application Continuity Protection Check

The Application Continuity Protection Check (ACCHK) feature generates Application Continuity coverage reports and views that describe the protection of your application by Application Continuity.

About Application Continuity Protection Check

The Application Continuity Protection Check (ACCHK) utility provides protection guidance for applications that use Application Continuity.

ACCHK provides guidance on the level of protection for each application that uses Application Continuity and helps guide you to increase protection, if required. ACCHK uses Application Continuity traces to collect coverage for a workload and provides detailed information as per your request. You must enable Application Continuity tracing to collect coverage before you run a database workload. ACCHK also provides diagnostics for an unsuccessful failover.

Database views and PL/SQL-based reports show you the level of protection for your applications for failover. If an application is not fully protected, then ACCHK identifies that application, finds out the reason why the application is not fully protected, and guides you how to increase the protection.

For the protected applications, ACCHK also reports which operations of an application are protected, and which operations of an application are not protected. If any operation or configuration of an application is not protected by the Application Continuity, then you can make configuration changes to increase the protection coverage. ACCHK generates a report with coverage statement and percentage value for the workload. The ACCHK report also shows how many operations were performed, how many operations were fully protected, and how many operations were not fully protected.

Related Topics

Enabling and Disabling Application Continuity Protection Check

You can manually enable or disable the Application Continuity Protection Check (ACCHK) feature for applications that use Application Continuity.

Application Continuity Protection Check is not enabled by default. Follow this procedure to enable or disable ACCHK and generate reports to check protection level for the applications.

  1. Grant read access to the users, who will run the Application Continuity Protection Check report and views, using the ACCHK_READ role:

    GRANT ACCHK_READ TO USER;
  2. Enable Application Continuity tracing for your applications using the dbms_app_cont_admin.acchk_set(true) procedure: 
    SQL> execute dbms_app_cont_admin.acchk_set(true);

    By default, ACCHK is disabled automatically after 600 seconds. You can specify a lower number to reduce the auto disable time. For example, use the dbms_app_cont_admin.acchk_set(true,300) procedure to disable ACCHK after 300 seconds.

    Note:

    On a read-only database or PDB, you must manually stop ACCHK data collection. Automatic disabling requires a Scheduler job to be created on the primary database, so do not rely on the default timeout or a specified disable time to stop data collection on a read-only database or PDB. After completing data collection, disable ACCHK tracing by running the following command:

    SQL> EXECUTE DBMS_APP_CONT_ADMIN.ACCHK_SET(FALSE);

    The dbms_app_cont_admin.acchk_set(true) procedure enables Application Continuity tracing at the database level to which you are connected. If you are connected at the CDB level, then tracing is enabled for the CDB, and if you are connected at the PDB level, then tracing is enabled for the PDB.

    Note:

    Set the COMPATIBLE parameter to 19c or greater. If the COMPATIBLE parameter was previously set to a lower value, then the acchk_set procedure creates the ACCHK views and roles when you run the procedure for the first time after updating the COMPATIBLE parameter.

  3. Use the dbms_app_cont_admin.acchk_set(false) procedure to disable Application Continuity tracing for new sessions in your applications:

    SQL> execute dbms_app_cont_admin.acchk_set(false);

    Note:

    • The tracing will be disabled for the current sessions after the time expires.
    • The tracing is enabled by default for the entire Oracle Real Application (Oracle RAC) Cluster.

Related Topics

Generating an Application Continuity Protection Check Report

Generate the Application Continuity Protection Check (ACCHK) report to get guidance for the level of protection, reason for incomplete protection, and methods to increase the protection level.

The ACCHK utility is a post-processing tool that uses ACCHK tables in AUX to report Application Continuity coverage. Enable the Application Continuity tracing and Application Continuity Protection Check before running a workload and generating the report.

When in read-only mode, traces can record event and statistics. The parameter source in ACCHK_REPORT is used to decide which input will use the procedure for displaying the report. You can choose either from tables or traces. When the database is in read-only mode, set this parameter to DBMS_APP_CONT_REPORT.FROM_TRACES.

  1. Run a set of database options after enabling ACCHK and tracing for your applications.

    ACCHK generates reports only for the Application Continuity sessions.

  2. Generate the Application Continuity Protection Check report using the dbms_app_cont_report.acchk_report procedure: 
    SQL> SET LINESIZE 350;
SQL> SET SERVEROUTPUT ON FORMAT WRAPPED;
SQL> execute dbms_app_cont_report.acchk_report;

    You can specify the type of the report from FULL, WARNING, or SUMMARY. For example:

    SQL> SET LINESIZE 350;
SQL> SET SERVEROUTPUT ON FORMAT WRAPPED;
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.FULL);
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.WARNING);
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.SUMMARY);

    The default report type is SUMMARY.

  3. Analyze the report and increase the protection level for the applications that are not fully protected. For example, a summary report looks like the following:

    --------------------------------------
------------ ACCHK Report ------------
--------------------------------------
CON_ID SERVICE       FAILOVER PROTECTED_ PROTECTED_ REQUESTS AVG_CALLS/ PROTECTED_    AVG_TIME/  PROTECTED_TIME/ EVENT_  ERROR_ PROGRAM   MODULE            ACTION    SQL_ CALL      TOTAL
                              CALLS %    TIME %              REQUEST    CALLS/REQUEST REQUEST MS REQUEST MS      TYPE    CODE                                         ID                
------ ------------- -------- ---------- ---------- -------- ---------- ------------- ---------- --------------- ------- ------ --------- ----------------- --------- ---- --------- ------
3      srv_tacr_pdb1 AUTO     98.734     98.432     117      9.453      9.333         2279.751   2244.014        DISABLE 41409  JDBC Thin AddCustNewOrder   Action-20      COMMIT    1     
                                                                                                                                Client                                                     
3      srv_tacr_pdb1 AUTO     98.734     98.432     117      9.453      9.333         2279.751   2244.014        REPLAY_ 41412  JDBC Thin InsertNewChecksum Action-1       SQL/PLSQL 1     
                                                                                                                 FAILED         Client                                     Execu           
End of report.

The following examples show how to query detailed information from an ACCHK report using the ACCHK views.

Example: Using the DBA_ACCHK_EVENTS View

In this example, the last row indicates that the application that is using the srv_tacr_pdb1 service has an event that caused Application Continuity to fail.

SQL> SELECT * FROM DBA_ACCHK_EVENTS ORDER BY TIMESTAMP;
INST_ID CON_ID TIMESTAMP        SESSION_ID SERIAL# SERVICE_NAME  PROGRAM  MODULE            ACTION    SQL_ID CALL_NAME EVENT_TYPE ERROR_CODE
------- ------ ---------------- ---------- ------- ------------- -------  ----------------- --------- ------ --------- ---------- ----------
2       3    21-SEP-20          9598       1644    srv_tacr_pdb1 JDBC     AddCustNewOrder   Action-36        COMMIT    DISABLE    41409
             06.54.18.191 PM                                     Thin
             -07:00                                              Client
2       3    21-SEP-20          1703       61265   srv_tacr_pdb1 JDBC     InsertNewChecksum  Action-1        SQL/PLSQL REPLAY_    41412
             06.51.07.624 PM                                     Thin                                        Execution FAILED
             -07:00                                               Client

Example: Using the DBA_ACCHK_EVENTS_SUMMARY View

In this example, the last row indicates that the application that is using the srv_tacr_pdb1 service has an event that caused Application Continuity to fail.

SQL> SELECT * FROM DBA_ACCHK_EVENTS_SUMMARY ORDER BY SERVICE_NAME;
INST_ID CON_ID SERVICE_NAME  FAILOVER_TYPE FAILOVER_RESTORE RESET_STATE PROGRAM MODULE            ACTION    SQL_ID CALL_NAME EVENT_TYPE ERROR_CODE FREQUENCY
------- ------ ------------- ------------- ---------------- ----------- ------- ----------------- --------- ------ --------- ---------- ---------- ----------
2       3      srv_tacr_pdb1 AUTO          AUTO             LEVEL1      JDBC    AddCustNewOrder   Action-20        COMMIT    DISABLE    41409      1
                                                                        Thin                                       Execution
                                                                        Client
2       3      srv_tacr_pdb1 AUTO          AUTO             LEVEL1      JDBC    InsertNewChecksum Action-1         SQL/PLSQL REPLAY_    41412      1
                                                                        Thin                                       Execution FAILED
                                                                        Client

Example: Using the DBA_ACCHK_STATISTICS View

In this example, the first row indicates that the application that is using the srv_tacr_pdb1 service has 11 implicit requests from JDBC and 31 calls in the application. 30 calls in these requests are protected.

SQL> SELECT * FROM DBA_ACCHK_STATISTICS ORDER BY TIMESTAMP;
INST_ID CON_ID TIMESTAMP        SESSION_ID SERIAL# STAT_TYPE  SERVICE_NAME  FAILOVER_ FAILOVER_ RESET_ PROGRAM  BEGIN_   END_     USER_CALLS_ PROTECTED_CALLS_ TIME_IN_ TIME_PROTECTED_
                                                                            TYPE      RESTORE   STATE           REQUESTS REQUESTS IN_REQUESTS IN_REQUESTS      REQUESTS IN_REQUEST
------- ------ ---------------- ---------- ------- ---------- ------------- --------- --------- ------ -------  -------- -------- ----------- ---------------- -------- ---------------
2       3      21-SEP-20        5653       54237   SESSION_   srv_tacr_pdb1 AUTO      AUTO      LEVEL1 JDBC     11       11       31          30               13316750 12415247
               06.54.25.321 PM                     STATISTICS                                          Thin
               -07:00                                                                                  Client
2       3      21-SEP-20        11291      26560   SESSION_   srv_tacr_pdb1 AUTO      AUTO      LEVEL1 JDBC     3        3        50          49               13094072 13068259
               06.54.24.915 PM                     STATISTICS                                          Thin
               -07:00                                                                                  Client

Example: Using the DBA_ACCHK_STATISTICS_SUMMARY View

In this example, the application that is using the srv_tacr_pdb1 service has 144 implicit requests, 99.5688328 percent calls in these requests are protected by Application Continuity or Transparent Application Continuity.

SQL> SELECT * FROM DBA_ACCHK_STATISTICS_SUMMARY ORDER BY SERVICE_NAME;
INST_ID CON_ID SERVICE_NAME  FAILOVER_ FAILOVER_ RESET_ TOTAL_   PROTECTED_CALLS_ PROTECTED_TIME_ AVG_USER_CALLS_ AVG_PROTECTED_    AVG_TIME_   AVG_TIME_
                             TYPE      RESTORE   STATE  REQUESTS PERCENT          PERCENT         IN_REQUESTS     CALLS_IN_REQUESTS IN_REQUESTS PROTECTED_IN_REQUESTS
------- ------ ------------- --------- --------- ------ -------- ---------------- --------------- --------------- ----------------- ----------- ---------------------
2       3      srv_tacr_pdb1 AUTO      AUTO      LEVEL1 144       99.5688328       99.0130288      22.5486111      22.4513889         3078654.35  3048268.92

Related Topics

Filtering Statistics and Events

ACCHK can gather the statistics and events by filtering the data through a service, module, program, or machine name.

When you provide single service filter or multiple service filters, ACCHK records only the statistics and events related to the specified services. This functionality also applies when you provide only a single or multiple program filters for only a single or multiple module filters. Provide a service, program, module, and machine filter for ACCHK to record only the statistics and events that match the service, program, module, and machine.

The DBMS_APP_CONT_ADMIN package contains the following procedures for filtering data:

  • ACCHK_SET_FILTER
  • ACCHK_CLEAR_FILTER
  • ACCHK_SHOW_FILTERS

Note:

After adding filters by using ACCHK_SET_FILTER, you must run ACCHK_SET(TRUE) to load the filters. If you add or clear a filter, but do not run ACCHK_SET(TRUE), then that particular filter is not updated.

Filter Life Span

  • Filters are accumulative.
  • The ACCHK_CLEAR_FILTER procedure clears one or all filters depending on how you run the procedure.

Related Topics

Cleaning Up ACCHK Collected Information

You can purge the information collected by ACCHK after the ACCHK reports are generated and data gathered from ACCHK views is analyzed.

Purging the ACCHK collected information is optional. You can initiate a new ACCHK process with new collected data after purging existing ACCHK information.

Use the following statement to purge all previously collected ACCHK information:

SQL> execute dbms_app_cont_admin.acchk_purge(purge_all => TRUE);

Related Topics

Delaying the Reconnection in Application Continuity

Learn about how you can set parameters to manage reconnects with Application Continuity, or Transparent Application Continuity, and see examples on single-instance and Oracle Real Application Clusters (Oracle RAC) databases.

Understanding How to Wait for the Service to be Ready for Application Continuity

To manage planned and unplanned outages, learn about the parameters that you use to manage application continuity.

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. For this reason, the failover must be delayed until the service is available from another instance or database.

To manage connecting and reconnecting, you must use the RETRY_COUNT and RETRY_DELAY parameters in your TNS or URL. These TNS parameters can work well in conjunction with a planned outage, for example, an outage that may make a service unavailable for several seconds. While setting the RETRY_COUNT and RETRY_DELAY parameters, check the value of the REPLAY_INITIATION_TIMEOUT parameter first. A high value for the RETRY_DELAY parameter can cause replay to be canceled.

Parameter NamePossible ValueDefault Value
RETRY_COUNTPositive integer zero or above30
RETRY_DELAYTime in sec, ms, or cs3

Creating Services on Oracle RAC with Application Continuity

You can create services on Oracle RAC that utilize Transparent Application Continuity or Application Continuity.

Note:

The policy-managed database deployment option is desupported in Oracle AI Database 26ai.

You can create services that use Transparent Application Continuity, as follows:

$ srvctl add service -db mydb -service TACSERVICE -pdb mypdb -preferred inst1 -available inst2
  -failovertype AUTO -session_state AUTO -failover_restore AUTO -commit_outcome TRUE -replay_init_time 600
  -retention 86400 -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE -role PRIMARY

You can create services that use Application Continuity, as follows:

$ srvctl add service -db mydb -service ACSERVICE -pdb mypdb -preferred inst1 -available inst2
  -failovertype TRANSACTION -session_state DYNAMIC -failover_restore LEVEL1 -commit_outcome TRUE  -replay_init_time 600
  -retention 86400 - notification TRUE -drain_timeout 300 -stopoption IMMEDIATE -role PRIMARY

Modifying Services on Single-instance Databases to use Application Continuity

If you are using a single-instance database, then use the DBMS_SERVICE package to modify services.

For Application Continuity:

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('FAILOVER_RESTORE'):='LEVEL1';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/

For Transparent Application Continuity:

DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='AUTO';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='AUTO';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/

Running Without Application Continuity

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.

Related Topics

Disabling Replay in Application Continuity

Learn about how you can disable replay with applications, and about specific rules and guidelines for disabling replay.

The rules described in this section are generic. They apply to all applications that replay work, including Application Continuity, and TAF (release 12.2 and after).

Understanding Enabling and Disabling Replay in Application Continuity

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

If an application has requests that you do not want the application to repeat, then the application either can take a connection to a service that does not have Application Continuity enabled, or the application 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 either to understand the application, or to disable requests with side effects.

When using Application Continuity, all calls are replayed. If an application uses UTL_SMTP, for example, and you do not want that application to repeat messages, then the application can use a connection to a different service, or use the disableReplay API on Java, or use the OCIRequestDisableReplay API for Oracle Call Interface (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.

Related Topics

Application Synchronizes Independent Sessions

If the application synchronizes independent sessions using volatile entities that are held until COMMIT, ROLLBACK, or session loss, then you must not configure an application for replay.

For example, if an application synchronizes multiple sessions connected to several data sources that are otherwise interdependent using resources such as a database lock, then this synchronization can be acceptable if the application is only serializing these sessions, and understands that any session can 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 can be invalidated when replaying.

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

Application Uses Time at the Middle Tier in the Processing Logic

If the application uses the wall clock at the middle tier as part of the processing logic, then you must not configure an application for replay.

The client driver does not repeat the middle tier time logic, but instead uses the database calls that run as part of this logic. For example, an application using middle-tier time might assume that a statement processed at Time T1 is not re-processed at Time T2, unless the application explicitly does so.

Application Assumes that ROWIds Do Not Change

If an application caches ROWID values, then access to these ROWID values can be invalidated due to database changes.

Although a ROWID uniquely identifies a row in a table, a ROWID can 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 Oracle GoldenGate, or other replication technology.
  • The database of the underlying table is flashed back or restored.

In general, Oracle does not recommend that an application stores ROWID values for later use, because the corresponding row either might not exist, might contain completely different data. Note that using ROWID values do not prevent using Application Continuity. Replays can be rejected.

Application Assumes that Location Values Do Not Change

If you have applications that use physical identifiers, then review the guidelines and examples here to avoid issues.

SYSCONTEXT options comprise two sets:

  • A location-independent set, such as National Language Support (NLS) settings, ISDBA , CLIENT_IDENTIFIER , MODULE , and ACTION
  • A location-dependent set, which uses physical locators

Typically, an application does not use the physical identifiers, 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 between requests (before beginRequest) or in callbacks. A common issue is for QA to modify test applications to select V$INSTANCE. As V$INSTANCE can change, only put this check in the callback, or select the instance locally at the client and not from the database.

Example of Physical Identifier Use

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;

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

Autonomous transactions, external PL/SQL calls, and Java callouts 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 the following:

  • Writing to an external table, sending email, forking sessions out of PL/SQL(including calls to UTL_HTTP , UTL_URL , UTL_FILE , UTL_FILE_TRANSFER , UTL_SMPT, UTL_TCP , UTL_MAIL, DBMS_PIPE , or DBMS_ALERT )
  • Writing to an external table, sending email, forking sessions out of Java (including running a shell script in the form Process proc = rt.exec(command); ), transferring files, and accessing external URLs

Actions such as these leave persistent side effects. PL/SQL messaging and Java callouts can leave persistent results behind. For example, if a user walks away partway through some work without committing, and the session times out, or the user issues a Ctrl+C command, then the foreground or a component fails. As a result, the main transaction rolls back, while the side effects may have been applied.

Application developers 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 you do not want these kinds of external actions replayed, then use a connection without application continuity, or use one of the disable replay APIs.

Related Topics

Terminating or Disconnecting a Session Without Replay

Learn how to disable replay when a DBA terminates or disconnects a session by using the ALTER SYSTEM KILL SESSION or ALTER SYSTEM DISCONNECT SESSION statement.

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. For example:

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.

Related Topics