The Oracle Call Interface (OCI) is a set of APIs which provides interaction with an Oracle database. It supports all phases of a SQL statement execution.
If you ever wondered how to trace OCI function calls you can do it by setting EVENT_10842 environment variable.
Further you can have the trace files generated in a specific directory by setting ORA_CLIENTTRACE_DIR=directory_path.
For ORA_CLIENTTRACE_DIR to take effect Automatic Diagnostic Repository (ADR) has to be disabled. You can disable it by setting DIAG_ADR_ENABLED=off in your sqlnet.ora.
A tracefile is generated for each connection in the format of ora_skgu_.trc1 where pid is the process id of the connection on the (client) system.
I will demonstrate an example trace of a DML statement, SELECT statement and one statement which throws an error. The OCI function calls varies, depending on the statement that’s executed. For example if we have SELECT statement we should see OCI fetch calls.
At the beginning of the trace file we have the OCIHandleAlloc – function which returns the pointer to the allocated handle.
The type of the handle is htype = service hndl which stands for Service Handle. Under the service context handle there are additional three handles allocated:
Server handle: establish the physical database connection
User session handle: defines the user’s domain (privileges, roles etc.)
Transaction handle: context in which statements are executed, PL/SQL packages initialized, fetch state etc.
The DML statement I’m using in this example is inserting a row in two columns table.
For the insert (DML) statement another htype = statement hndl handle is allocated.
You can also see the statement executed, it’s shown at OCIStmtPrepare and OCIStmtExecute entries.
The first step is for the statement to be prepared for execution, this step is executed under OCIStmtPrepare function call.
stmt = INSERT INTO t23(N1, V1) VALUES(:1 ,:2 ) – the actual statement
stmt_len = 39 – the length of the statement
language = OCI_NTV_SYNTAX – the language type for syntax check
On line 5, OCIAttrGet is called to identify the statement type via the attribute OCI_ATTR_STMT_TYPE, in this case it’s OCI_STMT_INSERT.
The statement is executed via OCIStmtExecute, line 8.
After execution, the OCI_ATTR_ROW_COUNT attribute is retrieved which stands for “Number of rows successfully converted in the last call to”. The same see with SQL%ROWCOUNT.
The transaction is committed with OCITransCommit function call. In this case the default flags = OCI_DEFAULT is used, for one-phase commit since the transaction is non-distributed.
After the statement is executed several OCI function calls are called (OCISessionEnd and OCIServerDetach) to end the session and detach the connection. Followed by several OCIHandleFree calls to clean several previously allocated handles.
Also for each connection there is an error handle allocated which is used to record information if an error occurs. Let’s simulate this with an insert statement which will fail with ORA-01722: invalid number
The error code is reported via OCIErrorGet function call, in this case errcodep = 1722.
The statement which was executed:
For a SELECT statement there are multiple OCIStmtFetch calls, depending on the array size. I’ve used default array size of 15 and which is noted in nrows.
It’s not likely that you will need to perform OCI calls tracing on a daily basis.
However, it can be useful in troubleshooting some issues at OCI call level.