Forum Stats

  • 3,734,708 Users
  • 2,247,029 Discussions


19c Where is OCI_THREAD SET? Seeing same issue as

We encountered the same issue as     after migrating to Oracle 19C.  We did the following work around and are not seeing the two threads now.  Where is  OCI_THREADED set in 19c.  This never occurred until after the 19c upgrade. 

So if you can tell us where OCI_THREADED is set in 19c, maybe down in the client install somewhere?  We can not find explicit reference to OCI_DEFAULT or OCI_THREAD

Description of the problem we were seeing listed below which is similar to the 4266189 thread above.  Found work arounds listed in the bug fixes.

The Pro*C code does not use oci. The application is expected to be a single thread.  The application runs as expected when compiled and executed in 12.2.  It does not work when compiled and executed using 19.3.

Our application is Pro*C code compiled in 64 bit mode against 19c. We’re calling EXEC SQL CONNECT. (the call in the generated code is sqlcxt()).  Our main process just stays in the system call sigsuspend() forever, because the Oracle thread caught our SIGCHLD.

Our thread never comes out of the sigsuspend(). The threads don’t talk (the first doesn’t even know about the second one).

Below are the process steps for our application.

  1. Subsystem process starts and sets up a signal handler for SIGCHLD.
  2. Process connects to the database.
  3. Process blocks SIGCHLD
    1. The process fork/exec a child.
    2. The process calls sigprocmask() and then suspends waiting on the child process to exit.
      1. By catching the SIGCHLD
  4. Process unblocks SIGCHLD and proceeds.

After the 19c upgrade, Oracle creates a new thread for the subsystem process when it connects (step 2 above).  The new thread will catch the SIGCHLD (from step 3).  The signal is not ever seen by the main process which leaves it forever suspended waiting for the SIGCHLD.

It is a timing thing.  When we put debug messages in the code to see where we are getting to, the problem does not happen.  I guess writing to disk changes the timing enough to allow the signal to go to the correct thread.

Doing a ps -L on the client processes will show multiple threads for our 19c code, while doing the same thing for the same processes on 12.2 only shows a single thread.

So far It looks like the work around listed in the bugs fixed our problem.  Please review the thread 4266189 above.  Work around:

  Disable the client statistic feature of 19c according to the following steps.

    1) Setting an initialized parameter CLIENT_STATISTICS_LEVEL to OFF only on a database side.

    2) Restart a database

We are not seeing the multi threads but we still do not know where OCI_THREAD is set in Oracle 19C and why did this start in 19C?  Is this a major change introduced some how in 19C?

Sign In or Register to comment.