Try passing ora_envhp => 0 in the connect() attributes. If that fixes it then the bug is probably that dbd::oracle should not use a cached environment handle if it's not usable. (and OCIHandleAlloc(OCI_HTYPE_ERROR) is a reasonable way to test that the environment handle is usable).
Tim. On Fri, Jun 05, 2009 at 04:41:51PM -0500, Tim Heath wrote: > Hello all - > > This problem/question may be more appropriate for the mod_perl list but I > thought I would try my luck here as well. I have a DBI-equipped CGI > application (triggered via https) that queries an Oracle 10.2.0.4 database. > During testing, when I try to query the database after a shutdown, the > database connect attempt returns an appropriate error, which is of course > expected: > > ORA-01034: ORACLE not available > ORA-27101: shared memory realm does not exist > Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: > OCISessionBegin) > > Unfortunately, even after the database is back up again, the apache worker > that was used for the failed connect attempt will continue to fail on > connect. In other words, when the database is up again, I can issue https > requests to the CGI and query the database normally until apache rotates to > the worker that had the initial connect error, and that worker will > consistently fail to connect with the following: > > OCIHandleAlloc(OCI_HTYPE_ERROR) > failed at > /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBD/Oracle.pm > line 232 > > Restarting the apache server clears the problem. > > It's all tied to mod_perl. If I disable mod_perl the problem does not > occur. The problem is consistently reproduceable and occurs with or without > Apache::DBI. > > Has anyone seen anything similar? > > Here is my environment: > > Redhat RHEL5, kernel build 2.6.18-128.1.10.el5, x86_64 > Perl v5.8.8 x86_64-linux-thread-multi (stock RHEL5) > Apache 2.2.3 (stock RHEL5 using preforked workers, no multithreading) > mod_perl version 2 (stock RHEL5) > DBI v1.607 > Oracle DBD v1.22 > > Thanks in advance > > Tim Heath > Qwest Communications
