Hello all,
I am a relative newbie at debugging DBI related problems. I am using
the following tracing:
PerlSetEnv DBI_TRACE "1=/tmp/dbitrace.log"
My problem is that although I can trace to lines of code in a package we
have written,
I don't understand what I can do because I don't fully understand the trace
output.
Here is as tight an example as I could find:
-> DBI->Apache::DBI::connect(DBI:Oracle:MOBILE1S, MOBILET3, MOBILET3)
[stuff deleted]
<- err= undef at Session.pm line 667.
<- execute= '0E0' at Session.pm line 676.
<- err= undef at Session.pm line 677.
[ stuff deleted]
<- finish= 1 at Session.pm line 709.
<- DESTROY= undef at Session.pm line 172.
-> DBI->Apache::DBI::connect(DBI:Oracle:MOBILE1, MOBILET3, MOBILET3)
<- FETCH= 'Oracle' ('Name' from cache) at DBI.pm line 64.
2 <- prepare('select SYSDATE from DUAL /* ping */')=
DBI::st=HASH(0x8a67260) at Oracle.pm line 307.
<- FETCH= 1 at Oracle.pm line 309.
<- DESTROY= undef at Oracle.pm line 311.
<- ping= 1 at DBI.pm line 112.
<- STORE('PrintError', 0)= 1 at DBI.pm line 407.
<- STORE('AutoCommit', 0)= 1 at DBI.pm line 407.
<- connect= Apache::DBI::db=HASH(0x884d9c8)
<- FETCH= 1 at DBI.pm line 153.
<- FETCH= '' at DBI.pm line 153.
!! ERROR: 3113 'ORA-03113: end-of-file on communication channel (DBD
ERROR: OCITransRollback)'
<- rollback= '' at DBI.pm line 153.
<- FETCH= 1 at DBI.pm line 153.
<- FETCH= '' at DBI.pm line 153.
<- rollback= 1 at DBI.pm line 153.
(1) Although this seems like a destroy-before-disconnect problem, I cannot
find that happening in my code,
which is Session.pm.
(2) I am not 100% sure of what causes the ORA-03113 error.
(3) I don't understand exactly what "DESTROY= undef at Oracle.pm line 309"
means, and whether that is
Bad or not. Also I am a little vague on the general semantics of the
Trace; the man pages don't seem
much help.
Basically I have this trace output but don't understand how to diagnose the
problem from it, I need to
know exactly what it means. The bug is very predictable and reproduceable;
we're running through Oracle::DBD
on Linux. I need a more specific understanding of this trace, as well as
better ways to debug such a DB
problem.
Can anybody help?
--John Hempe
