Tim Bunce wrote: > On Fri, Apr 24, 2009 at 10:20:07AM +0100, Martin Evans wrote: >> Hi, >> >> Early this morning a perl process of ours got the following error >> on stderr: >> >> DBD::Oracle::db do failed: ORA-24909: call in progress. Current >> operation cancelled (DBD ERROR: OCIStmtExecute) at >> /usr/lib/perl5/site_perl/5.8.8/DBIx/Log4perl/ db.pm line 83. > > (Setting ShowErrorStatement may help if you're not sure which > statement was affected.) > >> The first significant thing is that it was output on stderr and not >> caught by DBI/DBD::Oracle and therefore not signalled as a normal >> error (DBIx::Log4perl has a DBI error handler which never saw it). > > I'm not sure what you meant by "not caught by DBI/DBD::Oracle". The > "DBD::Oracle::db do failed:" prefix is only added by the > PrintError/RaiseError/HandleError code.
We don't output anything to stderr ourselves. We have a DBI error handler and it was not called as far as I can see. The error handler catches all errors and logs them to a file - there was nothing in it and we didn't run out of disk space or hit a file size limit on any log files. >> Our code is not threaded. Oracles documentation says: >> >> The OCI call was invoked when another call on the connection was in >> progress. Check if the OCI call is supported when the call is in >> progress under special conditions; for example, if it is being used >> by a signal handler. What this means is that an OCI call (Oracle >> call interface, the lowest language you can program in to access >> the Oracle database) is issued, while another call is still being >> executed. eg: one OCI call tries to read a cursor, but another OCI >> call, which closes the cursor is already in progress. > > As it says, check signal handlers, and perhaps exception handlers as > it might be possible for an exception from within a DBD::Oracle call > to leave a handle in a state where a later execute() would cause an > error. I've checked and the only code we have for signal handlers is for SIGINT and SIGTERM and neither of these was raised. All these handlers do is set a scalar the main program checks as they run in a loop. > Another thing to check is forking, in all it's forms, as the > sub-process would inherit the file descriptors and could cause > problems. We have no specific forking in our code and no calls to system or back tick operations. We do use quite a lot of modules so it is difficult for me to be 100% sure none of them do that. I found the same error mentioned in http://www.mail-archive.com/[email protected]/msg25191.html posted back in 2005 but no one answered it and the poster never said if/how it was resolved. I also found http://www.dbmotive.com/oracle_error_codes.php?errcode=24909. At the bottom it says: "There is a bug when using Oracle version 10.2.0.1 which causes this error. Should you be using this version, you might want to upgrade the version or your Oracle server and / or Oracle client." and as it happens we are using 10.2.0.1.0 so perhaps this is the problem. The only other data we have for the time is from a sqlnet.log showing from ./app/oracle/product/10.2.0/server/network/log/sqlnet.log Fatal NI connect error 12170. VERSION INFORMATION: TNS for Linux: Version 10.2.0.1.0 - Production Oracle Bequeath NT Protocol Adapter for Linux: Version 10.2.0.1.0 - Prod uction TCP/IP NT Protocol Adapter for Linux: Version 10.2.0.1.0 - Production Time: 24-APR-2009 09:40:30 Tracing not turned on. Tns error struct: ns main err code: 12535 TNS-12535: TNS:operation timed out ns secondary err code: 12606 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Client address: <unknown> and from a trc file: *** 2009-04-24 09:40:30.301 opiino: Attach failed! error=-1 ifvp=(nil) Problem is it has only happened once in over 2 years. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
