This isn't much of a DBI answer, but in Oracle 8.1.6.0 RedHat 6.2,
Killing the shadow process of a local sqlplus non-sqlnet connection
results in ora-12571: TNS:packet writer failure. I suppose the same
would happen with a dbi program, but I haven't read enough dbi
documentation to know how to connect locally without using sqlnet.
Killing the shadow process of a dbi sqlnet connection results in
ora-03113: end-of-file on communication channel. When I killed the
shadow process for a dbi 1.15 sqlnet connection, the program died with
ora-03113 but it did not have any problems retrieving the error text for
the 3113 error. I don't know where DBI programs get the Oracle
error-message text (and I would LIKE to know, in case anyone wants to
pass it along), but my dbi program handled the ora-3113 message text
correctly. Anyhow, it is possible for shadow processes to die if you
do strange things with your programs - not that I recognize anything
strange about your code, but I have seen it happen.
I speculate that you are connected via sqlnet and that your shadow
process is dying for some reason, which is your primary problem. It's
possible but not certain that the death of the shadow process is being
caused by your program. For some reason dbi can't find the error
message text, but I suspect this is a secondary problem.
I presume the core dump you mention is a client core dump. Since the
shadow process runs on the server, you might want to look in the Oracle
dump directory on the server for evidence of a server-side event related
to your program. There might be something in an alert log or in a dump
file that gives you more of a clue as to the cause of the death of a
shadow process and how it might be related to the change in your
program. Emphasis is on "might", but I do seem to recall that
sometimes ora-3113 litters the server with alerts and/or dumps. I think
the above is true if you are not using the multi-threaded server.
I suppose dbi-ers would say turn on dbi_trace, or something like that.
I suppose you might get more client-side information that way.
Paul Kelley
Ali Zaidi wrote:
> Hi:
> I am trying to execute a piece of code that works in one
> variation and dumps core in another.
> The one which works is
>
> my ($stmt);
> eval {
> $stmt=$db->prepare_cached ("update job_queue set
> status_flag='JDP' where sid= $sid ");
> $stmt->execute;
> $stmt->finish;
> };
> if ($@) {
> $error_string=DBI->errstr;
> print "Some Error ".DBI->errstr."\n";
> $statement->finish;
> $db->disconnect;
> return -2;
> }
>
> Following is the part which dumps core. Please note that the
> only change is that i am trying to use a bind variable in this
> case.
>
> my ($stmt);
> eval {
> $stmt=$db->prepare("update job_queue set
> status_flag='JDP' where sid= ? ");
> $stmt->execute($sid);
> $stmt->finish;
> };
> if ($@) {
> $error_string=DBI->errstr;
> print "Some Error ".DBI->errstr."\n";
> $statement->finish;
> $db->disconnect;
> return -2;
> }
>
> Here is the error that gets dumped on the console
>
> DBD::Oracle::st execute failed: Error while trying to retrieve
> text for error ORA-03113 (DBD ERROR: OCIStmtExecute)
> at ./job_daemon.pl line 114.
> Segmentation Fault (core dumped)
>
> Would appreciate any input
>
> Thanks
> Ali
>
> ________________________________________________
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
