we are seeing ORA-56600 DRCP: Illegal Call messages irregurarely in our log. Unfortunately, the explanation of this error says "See manual" but searching the manuals and metalink revealed nothing about this error.
The occurence is random and the error happens at the first SQL in the script, no matter what the actual SQL is. The reload of the page works and the same SQL is executed OK. So I am not even posting the SQL, since it is not relevant.
My theory is, that the opened session somehow becomes "poisoned" by something we do elsewhere and all subsequent uses of this connection fail. I know, that you cannot use ALTER SESSION statements safely with DRCP and we checked and doble-checked and we are quite confident, that we do not issue any ALTER SESSION in our application. Are there any other "forbidden" constructs when using DRCP?
Does anyone have any ideas what to do next in order to hunt down the cause of this error? Or anybody knows what the error message actually means?
Our environment is:
Oracle Database 11g Release 22.214.171.124.0 - 64bit Production
With the Real Application Clusters option
OCI8 Support => enabled
Version => 1.3.4
Revision => $Revision: 1.2126.96.36.199.38.2.20 $
Active Persistent Connections => 0
Active Connections => 0
Oracle Instant Client Version => 11.1
Temporary Lob support => enabled
Collections support => enabled
The database runs RedHat 5 64bit, the application server is CentOS 4 64bit
Also, you have the instant client. You may want to install the full client since there was a patch set and some libraries have changed. You can patch 188.8.131.52 client to 184.108.40.206 but you cannot do that with the instant client.
I think it's something we do wrong, but the problem is I do not have any ideas how to find uout what it is. I hope we are not the first in the world to try to use DRCP, so I guess it's not actual bug in Oracle/oci8, but something we do. If only there was a way to know WHAT it is.
I also tried a different application server, 32bit linux, oci8 1.3.5 and the result is the same.
BTW, you should be able to use ALTER SESSION statements. With DRCP you just can't guarantee that a subsequent persistent connection will automatically inherit the changed session values. Using ALTER SESSION in a LOGON trigger is still an efficient way to ensure that every connection has the same session values set. See the whitepaper http://www.oracle.com/technology/tech/php/pdf/php-scalability-ha-twp.pdf
Chris, in my experience, we had problems with ALTER SESSION in a situation, when the sessions migrated from one instance to another. In our testing, we were issuing HTTP requests to an apache/php server, connected via DRCP to two RAC instances. The first SQL command of this script was an ALTER SESSION SET CURRENT_SCHEMA=something.
After we took one of the instances down, the sessions migrated to the other, but the ALTER would fail on the migrated connections with--and now I am not 100% sure but I think it was--the same ORA-56600 error.
I hope we will find out what it's caused by. I'll post results afterwards of course, because this error seems non-existent on the internets and hopefully it'll help some other poor soul.
Well, it was quite a challenge tracking it down, but with help from Oracle development, we have discovered that it's actually a bug in the statement cache. The bug has been filed as 8467564.
There is a workaround for it. The problem occurs, when the statement cache is lower than the maximum number of distinct SQL statements in one script run. So the workaround is either to disable the statement cache completely or increase the size of the cache to a much higher value.
The php.ini setting to adjust is:
The bug is now fixed in the 11.2 codeline. I have requested a one-off patch for 220.127.116.11, we'll see if it goes thru.
Hey.. I'm having that same exact error but the above did not fix it in our environment..
OCI8 Support enabled
Revision $Revision: 313688 $
Active Persistent Connections 1
Active Connections 1
Oracle Run-time Client Library Version 18.104.22.168.0
Oracle Instant Client Version 11.2
Temporary Lob support enabled
Collections support enabled
Directive Local Value Master Value
oci8.connection_class myNavyExchange myNavyExchange
oci8.default_prefetch 100 100
oci8.events On On
oci8.max_persistent -1 -1
oci8.old_oci_close_semantics Off Off
oci8.persistent_timeout -1 -1
oci8.ping_interval 180 180
oci8.privileged_connect Off Off
oci8.statement_cache_size 1000 1000
Are all your mid-tier PHP's binaries using the same version of the Oracle Client and same settings?
It'll probably be best to work through Oracle Support to resolve this since they can dig into your configuration, application behavior and traces etc more quickly than forum exchanges will achieve. Feel free to get me involved with the SR.