What was your testcase?

To force an OCIEnvNlsCreate failure you can always move or 
otherwise make inaccessible some of the instant client 
library files.

But the particular issue I am seeing on our production web 
server (running Red Hat EL 5) involves OCIEnvNlsCreate 
failing intermittently, and unfortunately we can't reliably 
reproduce it. All we know is, when it starts to happen, it 
seems to globally affect all web applications on the host 
for a few minutes (none of them can connect), then it goes 
away again.

I'm not saying that the oci8 extension is responsible for 
the problem we're seeing, but the fact that the error 
condition can't be trapped and identified by the PHP script 
(with oci_error()) is making it harder to track the problem 
and identify how frequently it's happening. A lot of 
applications (including Zend_Db) will suppress oci_connect() 
warnings with @ and then only log the output of oci_error().

I am seeing this error now for the last few months.
Very frustrating because no way to force it to happen.
As far as I know I changed nothing at all.
There must be some resource limit either in PHP or Oracle that 
is not being reported back as being exceeded.
The Apache logs (access and error) contain nothing.

Does anyone have a solution / update to this one ? I', experiencing similar issues on a clients site, and again its not repeatable.

It's a pity there is no useful information in this bug about the versions and 
environments this is seen on.  The root problem could be anywhere (including 
webserver memory corruption). However since the failure is coming from the 
environment setup, it's worth triple-checking the OCI8 environment is set 
correctly.  Make sure scripts don't use setenv() to set Oracle environment 
variables.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Code to print the Oracle error message has been added.  It may help but from 
previous experience I know it's not feasible to expect Oracle libraries to 
identify the real root causes of misconfigured systems.  So, if the root cause is 
some memory corruption from any subsystem involved, I wouldn't expect the 
messages to be reliable.

Server load about 9 scripts open during the minute of the corruption, each one  connected to the db, lasting approx 1 second each.
its PHP Version 5.1.4 
--with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client/lib,/usr/include/oracle/10.2.0.4/client' 
OCI8 Support  enabled  
Revision  $Revision: 1.269.2.16 $  
Active Persistent Connections  0  
Active Connections  0  
Oracle Instant Client Version  10.2  
oci8.default_prefetch 10 10 
oci8.max_persistent -1 -1 
oci8.old_oci_close_semantics 0 0 
oci8.persistent_timeout -1 -1 
oci8.ping_interval 60 60 
oci8.privileged_connect Off Off 
oci8.statement_cache_size 20 20 

No persistant connections are being made and every so often, we get a fail  to connect  (during busy times) resulting in the following in php error log.


[03-Nov-2011 17:11:22] PHP Warning:  ocilogon() [<a href='function.ocilogon'>function.ocilogon</a>]: OCIEnvNlsCreate() failed. There is something wrong with your system - please check that LD_LIBRARY_PATH includes the directory with Oracle Instant Client libraries in /disk1/********/db_class.php on line 17

about 90 , not 9

PHP 5.1.4 is over 5 years old now and I strongly suggest upgrading
some or all of the stack.  The connection management code in PHP OCI8
was changed a lot in OCI 1.4. You have what corresponds to OCI8 1.2.1.
This list of fixes since then is in http://pecl.php.net/package/oci8.

If you can't upgrade all of PHP, try upgrading only the OCI8 extension
using PECL.  Some steps are in "Upgrading PHP with PECL OCI8 on Linux"
on p 70 of
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-
098250.html
If you want yesterday's extra diagnostic from this bug, grab OCI8 code
in any of the 5.3/5.4/trunk bundles from http://snaps.php.net/

If you are using REF CURSORS (and not using Oracle Database 8i), I
suggest also upgrading Instant Client to 11.2 to get the pre-fetching
performance increase.  If you want to stick to the 10.2 stream, you
might be interested that 10.2.0.5 is available.

Depending on your platform, if you don't want to build PHP, you may be
able to test out the development-only PHP 5.3.8 RPMs from
http://oss.oracle.com/projects/php/ or perhaps use Zend Server.

Note this bug is closed.  Please follow up via email or a support
forum such as http://www.oracle.com/technology/forums/php.html