Application Continuity Checking for Application Continuity allows you to deploy Application Continuity easily and transparently in most cases.
Oracle ORAchk identifies any references to deprecated JDNVC concrete classes that need to be changed.
Oracle ORAchk analyzes the database operations in the application and reports the level of protection, and where applications are not protected. In places where applications are not protected, Oracle ORAchk reports why.
Together, these checks can help ensure that your application workload is covered by Oracle Application Continuity.
See Also:
Ensuring Application Continuity
Oracle White paper, Application Continuity with Oracle Database 12c, which is available at the following URL:
Application Continuity with Oracle Database 12c
Examples of using the newer Oracle JDBC types in place of the older Oracle concrete types, which is available at the following URL:
Application Continuity Checking for Concrete Classes
For Java applications only, determine whether the application uses deprecated Oracle JDBC concrete classes.
To use Application Continuity with Java, replace the deprecated Oracle JDBC concrete classes. For information about the deprecation of concrete classes including actions to take if an application uses them, see My Oracle Support Note 1364193.1:
New Jdbc Interfaces for Oracle types
To know if the application is using concrete classes, use Application Continuity checking (called acchk
in Oracle ORAchk). There is no need to use 12c driver or database, or to have source code for concrete class checks. The application can be verified in advance while planning for high availability for your application.
Application Continuity is unable to replay transactions that use oracle.sql
deprecated concrete classes of the form ARRAY
, BFILE
, BLOB
, CLOB
, NCLOB
, OPAQUE
, REF
, or STRUCT
as a variable type, a cast, the return type of a method, or calling a constructor.
Modify them for Application Continuity to work with the application.
Table 2-1 Application Continuity Checking for Concrete Classes
Command Line Argument | Shell Environment Variable | Usage |
---|---|---|
|
RAT_AC_ASMJAR |
This must point to a version of |
|
RAT_JAVA_HOME |
This must point to the |
|
RAT_AC_JARDIR |
To analyze the application code for references to Oracle concrete classes, this must point to the parent directory name for the code. The program analyzes |
Example
The following command checks the Application Continuity checking for Oracle concrete classes.
$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome /tmp/jdk1.8.0_40 -appjar /tmp/appdir
Outage Type Status Message Concrete class checks Total : 19845 Passed : 19610 Warning : 0 Failed : 235 (Failed check count is one per file) FAILED [oracle/jdbc/driver/ArrayDataResultSet] [[CAST]desc= oracle/sql/STRUCT method name=getObject, lineno=1477] FAILED [oracle/jdbc/driver/ArrayDataResultSet] [[CAST]desc= oracle/sql/NCLOB method name=getNClob, lineno=1776] FAILED [oracle/jdbc/driver/BfileAccessor] [[Method]name=getBFILE, desc=(I)Loracle/sql/BFILE;, lineno=99] FAILED [oracle/jdbc/driver/BlobAccessor] [[Method]name=getBLOB, desc=(I)Loracle/sql/BLOB;, lineno=129] FAILED [oracle/jdbc/driver/ClobAccessor] [[Method]name=getCLOB_, desc=(I[B)Loracle/sql/CLOB;, lineno=230] FAILED [oracle/jdbc/driver/ClobAccessor] [[Method] name=getCLOB, desc=(I)Loracle/sql/CLOB;, lineno=226]
Application Continuity Checking for the Protection Level Application Continuity is Providing Your Application
Measure Coverage
Destructive testing is a good thing to do and definitely should be run. However, introducing failures is non-deterministic. The application can failover beautifully in all the tests, and then in production a failure occurs elsewhere and unexpectedly some requests do not failover.
Using AC Check Coverage Analysis averts this situation by reporting in advance the percentage of requests that are fully protected by Application Continuity, and for those are not fully protected, which they are and where. Use the coverage check in advance of deployment, and the 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 it can be fixed before the application is released or waived knowing the level of coverage.
Executing the coverage check is rather like using SQL_TRACE
. First run the application in a representative test environment with Application Continuity trace turned on at the server side. The trace is collected in the standard database user trace directory in user trace files. Then, pass this directory as input to Oracle ORAchk to report the coverage for the application functions that were run. As this check uses Application Continuity, the database and client must be using 12c. The application does not have to be released with Application Continuity. The check is to help you to release.
The following is a summary of the coverage analysis.
If a round-trip is made to the database server and returns while Application Continuity’ capture is enabled during capture phase, then it is counted as a protected call.
If a round-trip is made to the database server while Application Continuity’ capture is disabled (not in a request, or following a restricted call or a disable replay API was called), it is counted as an unprotected.
Round trips that are ignored for the purpose of capture and replay are ignored in the protection-level statistics.
At the end of processing each trace file, a level of protection for the calls sent to the database is computed.
For each trace: PASS (>= 75)
, WARNING (25 <= value <75)
, and FAIL (< 25)
Running the Coverage Report
Turn on tracing at either a session level or database level
beginRequest
so replay is not disabled by setting events):
alter session set events 'trace [progint_appcont_rdbms]';
alter system set event='trace[progint_appcont_rdbms]' scope = spfile;
Run through the application functions. To report on an application function, it needs to have executed. The more application functions run, the better the information that the coverage analysis provides.
Use Oracle ORAchk to analyze the collected database traces and report the level of protection, and where not protected, reports why a request is not protected.
Set the following four values through command line or shell environment variables (or mixed) to control the Application Continuity checking for coverage:
Table 2-2 Using Application Continuity Checking for Protection Level
Command Line Argument | Shell Environment Variable | Usage |
---|---|---|
|
RAT_AC_ASMJAR |
This must point to a version of |
|
RAT_JAVA_HOME |
This must point to the |
|
RAT_AC_TRCDIR |
To analyze the coverage, specify a directory name that contains one or more database server trace files. The trace directory is generally,
$ORACLE_BASE/diag/rdbms/{DB_UNIQUE_NAME}/$ORACLE_SID/trace |
NONE |
RAT_ACTRACEFILE_WINDOW |
When scanning the trace directory, this optional value limits the analysis to scanning to files created in the most recent specified number of days |
Example
$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome /tmp/jdk1.8.0_40 -apptrc $ORACLE_BASE/diag/rdbms/$ORACLE_SID/trace 3
Reading the Coverage Report
The coverage check produces a directory named orachk_uname_date_time
. This report summaries coverage and lists trace files that have WARNINGS or FAIL status. Also check in the PASS report (acchk_scorecard_pass.html
) in the reports directory to ensure all requests PASS (Coverage(%) = 100). To see all of the details, look for reports/acchk_scorecard_pass.html
under the outfile
subdirectory.
The output includes the database service name, the module name (from v$session.program
, which can be set on the client side using the connection property on Java for example, oracle.jdbc.v$session.program
), the ACTION
and CLIENT_ID
, which can be set using setClientInfo
with OCSID.ACTION
and OCSID.CLIENTID
respectively.
orachk_.....html#acchk_scorecard
Outage Type Status/Message Coverage checks Total : 19845 Passed : 19610 Warning : 0 Failed : 235 (Failed check count is one per file) [FAIL] Trace file name = SAMPLE_ora_1234.trc Row number = 2222 SERVICE NAME = (SAMPLE_WEB_SERVICE.OCS.QA) MODULE NAME = (DEBIT) ACTION NAME = null CLIENT ID = null Coverage(%) = 50 ProtectedCalls = 4 UnProtectedCalls = 4 [FAIL] Trace file name = SAMPLE_ora_5678.trc Row number = 7653 SERVICE NAME = (SAMPLE_WEB_SERVICE.OCS.QA) MODULE NAME = (PAYMENTS) ACTION NAME = null CLIENT ID = null Coverage(%) = 20 ProtectedCalls = 1 UnProtectedCalls = 4 [FAIL] Trace file name = SAMPLE_ora_90123.trc Row number = 15099 SERVICE NAME = (SAMPLE_WEB_SERVICE.OCS.QA) MODULE NAME = (PAYMENTS) ACTION NAME = null CLIENT ID = null Coverage(%) = 60 ProtectedCalls = 3 UnProtectedCalls = 2 [FAIL] Trace file name = SAMPLE_ora_4747.trc Row number = 789 SERVICE NAME = (SAMPLE_WEB_SERVICE.OCS.QA) MODULE NAME = (ACCOUNT) ACTION NAME = null CLIENT ID = null Coverage(%) = 50 ProtectedCalls = 2 UnProtectedCalls = 2
Related Topics