This content has been marked as final. Show 10 replies
If you can identify an OCI-related error or DB error than we will be able to get Oracle Support to look at the error. PHP OCI8 uses the OCI API; the OCI development team have contributed to OCI8 and they will be able to assist.
The Oracle DB 188.8.131.52 patch was released on support.oracle.com today for Linux 32 & 64 bit. Instant Client has not yet been bundled. But since you're using the full client it might be a quick, useful test to try your app with 184.108.40.206.
To identify a cause check all the normal trace files in the stack on client & server machines, including in the 11g oradiag_* directories. Try and minimize a testcase.
Thank you for the reply.
We did collect the database trace files (by using alter session set sql_trace=TRUE) and sent to Oracle support.
No Oracle errors found in these trace files on the database servers (our database servers are running on AIX machines).
With 220.127.116.11 database, the PHP program just stopped at some point. With 18.104.22.168 database the PHP program procceeds and generates more trace files without errors in them.
Our developer told me that his PHP program has no problem connecting to the database and run some SQL commands, but it terminates when collections are used to handle bulk data operations with the 22.214.171.124 database.
We will collect the database client side trace files (by setting the trace parameters in sqlnet.ora on the client Linux machine) to see if we can catch any OCI and/or DB errors. Thank you for your suggestion.
Do you know is there a way to catch errors on the Web Server (Apache Server) level and/or on the PHP level? Our PHP developer told me no errors found on our PHP environment. Which makes the troubleshooting very difficult.
Try turning on oci_internal_debug http://www.php.net/manual/en/function.oci-internal-debug.php
Also in php.ini turn on all the error checking http://php.net/manual/en/errorfunc.configuration.php
This should get you some more info and let you know if the failure is someplace on the web server. Don't forget to check your apache logs.
After more testings done by our developer, he told me that his PHP script works if he uses Oracle Client 126.96.36.199 with Oracle database 188.8.131.52 and uses Oracle Client 184.108.40.206 with Oracle database 220.127.116.11. When it's not working (Oracle client version and Oracle database version are different), the Oracle Error is :
Errors in file :
OCI-30757: Message 30757 not found; product=RDBMS; facility=OCI
Since the developer now can make his PHP script work. I am going to mark this question answered. Thank everyone for your help!
If I had to guess, I say it sounds like the developer is using
persistent connections and modifying SQL types as part of the
Hopefully the production application won't do this, since it can lead
to inconsistencies when the client (aka PHP) process information about
the type doesn't match the updated server description. In your case
it seems to have caused an error and the PHP process has had to abort.
During this phase of development you might want to use non-persistent
connections or restart Apache after each type change.
You have changed ORACLE_HOME. How do you set ORACLE_HOME when you start Apache? The right way is to set the home in /etc/sysconfig/httpd like this:
mgogala@mladen ~]$ head /etc/sysconfig/httpd
+# Configuration file for the httpd service.+
+# The default processing model (MPM) is the process-based+
+# 'prefork' model. A thread-based model, 'worker', is also+
+# available, but does not work with some modules (such as PHP).+
+# The service must be stopped before changing this variable.+
You can check by doing this: php -r 'phpinfo();'|grep -i oracle
If ORACLE_HOME, LD_LIBRARY_PATH and ORACLE_BASE aren't defined, there is an installation problem.