It's a known feature and will be probably fixed in future versions. 
Currently you can fix it yourself with uncommenting ociping() function in oci8.c and recompiling PHP. 
Or, much easier way, do not shutdown the database or restart Apache in the same time - all established connections will be discarded and ocilogon/oci_connect will establish new ones.

Thanks Tony.  Can I just clarify something - are you saying that oci_new_connect() and ocinlogon() don't actually establish new connections?  I was under the impression that these functions forced a new connection to be made.

Yes, these functions establish new connection. But this error can be also concerned with internal Oracle Interface Library problems (search this error message in google) and not with PHP. 
Nevertheless, PHP doesn't ping already established connections, because it would slow down things too much. Probably in the future we will add an ini setting for it, but currently ociping() is just disabled for perfomance reasons.

Getting a very similar problem with database on Solaris 8 64-bit Oracle 8.1.7.3.0 using Oracle 9.2.0.5 listener, PHP server 4.3.7 on RedHat Linux (2.4)/Apache 1.3.  Following weekly cold backup, PHP keeps trying to use cached persistent connections, giving ORA-24327 and/or ORA-03113 (end-of-file on communication channel).  Can trap the error, but can't figure out how to flush the dead connections from the connection cache!  Hate to cron an Apache restart daily...

I ended up using the oracle extension rather than the oci8 extension.  Have had no problems since.

Expiring the same problem on Linux (Fedora 2, Kernel 2.6.5). Restarting Apache with option graceful is okay in an internal environment but fixing this error would be very nice too ;-)

Getting a very similar problem after PHP-Upgrading with following system:
Solaris 8 32 bit Oracle 8.1.7.0.0 and Apache 2.0.52 PHP 5.0.3

After shutdown and startup database first I got ORA-03113 (end-of-file on communication channel) and then ORA-24327 (need explicit attach before authenticating a user). With the same system and PHP 4.3.10 I have no problems, because of that I think, it is too simple to say and not helpful, thats an Oracle-Problem.

I have the same error with PHP under Windows 2003/IIS accessing Oracle 8.1.7 with 8.1.7 client.
I have tried every thing that was sugested in this paper, but the error remains.

I am experiencing the same issue using IPL 6.1, php 5.0.3 and Oracle 9.2.0.6 64-bit, we are running on Solaris 8.  I need to find a better solution than restarting the server or as it has been indicated uncommenting ociping() from the oci8.c and recompiling since there are indications that this will degrade performance.

We are getting this bug regularly as well. We are using the Oracle-Instant-Client / php 5.0.3 / apache2 on a linux fedora 3 box.

well, I just wanted to note that. I encountered this
problem intermittently with:

   php-5.0.4/solaris-10/apache-1.3.33
   php-5.0.4/solaris-9/apache-1.3.29
   oracle's instantclient-10.1.0.3
   Oracle9i Enterprise Edition Release 9.2.0.5.0

from both:

   oci_connect/oci_new_connect($1, $2, $3).

I have the same "feature" (oci_connect(): OCISessionBegin: ORA-24327: need explicit attach before authenticating a user) using PHP 5.0.4 on Win2k SP4, Apache 2.0.47, Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production.
Unfortunately, I can't recompile oci8.c with ociping() enabled and it's very inconveniently to restart Apache every time database goes down. I hope you release some fix in the not too distant future. Because of this I need to use PHP 4.3...

I am experiencing the same problem on Apache 5.0.0 with Oracle 9.2.  Any solutions besides rebooting the Apache server are greatly appreciated as I cannot afford to reboot the apache server since I am unable to know when the database has gone down for certain.  I am capturing the error codes from OCIError and can determine the cause, but am unable (due to user abilities on the Linux system) to reboot Apache with a script, etc.  Fix on this ASAP would be greatly appreciated.

Why does 4.3.10 not have this problem?  Is it because it is doing the ociping() or similar which means that its performance is less than the 5.0?  Or just that the 5.0.x has special optimization with using the Oracle internal library?

What is the status of the fix?  Will it be in the next release or maybe the next next release?  How can I help to push the priority of the fix?  I perfer not to use 4.3.10 because I will need to re-test all my applications on 4.3.10, and I also prefer not to uncomment ociping() so that I don't have to degrade the performance...  In other words, I want everything :DDD

Thanks....

I use php 5.0.4 On mandrake linux, the bug remains;
but I can't see any ociping() function in oci8.c !!!!

I too would appreciate a quick fix to this feature (what does the suspended status mean?). I see the error message using PHP 5.0.4, Apache 2.0.54 on win2k talking to a remote Oracle 10g database through Instant Client.

BTW the suggestion to uncomment out ociping() in ori8.c may be for oci_ping() instead?  That's what's in the win php5 source anyway. I just need a compiler now (the ms visual c++ toolkit 2003 does not include msdev which is needed to build resolv.lib - what a thing to find out _after_ downloading and installing 1GB of mostly not needed packages). 

On the brighter side I am running windows so system crashes and reboots will make my admin job easier for once. :)

I had the same problem and wrote a small patch :
http://www.jeuxdecartes.net/static/oci8.ping_freq.patch

It adds a oci8.ping_freq php.ini variable (oci8.ping_freq = 60 is a good start).

The bug has been fixed in OCI8 v.1.1, which is available in CVS HEAD and PECL (use `pear install oci8-beta` to install it).