This content has been marked as final. Show 11 replies
Michael, the only component that could be issuing OCI calls in the game is oci8 driver for PHP. Your version is 1.3.4, the current version is 1.3.5. You can find the the change log here:
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 126.96.36.199 client to 188.8.131.52 but you cannot do that with the instant client.
Thanks for the suggestion. I upgraded the oci8 to 1.3.5 but no effect, it happens anyway.
We have the latest instantclient I guess:
[root@server ~]# rpm -qa | grep oracle
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.
Bye and thanks everyone,
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 184.108.40.206, we'll see if it goes thru.
Thanks to Chris for support on this.
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 220.127.116.11.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.