Re: How to interpret the following Oracle trace file?

The file looks truncated because it exceeds the max size you allowed by setting init.ora parameter max_dump_file_size (in units of OS blocks = 512 bytes on Unix). Increase it. This can be done dynamically but the new value will only apply to new sessions.

You say you have a problem interpreting it. Normally I don't read the trace file itself but I use tkprof:

   tkprof <tracefile> <outputfile> explain=<username/password> sys=no and read the outputfile. When you have specified explain=.... an execution plan is included as if the statement was executed by the given username. With sys=no recursive calls are not included in the output which makes it easier to interpret.
Our do you mean that tkprof won't run? Remove the last incomplete line and try it again. Sometimes tkprof finds the trace file "corrupt" and coredumps.

Brandon <brandon_oh_at_yahoo.com> schreef in berichtnieuws a03c2125.0205232035.ef5f99d_at_posting.google.com...
| Hi there,
|
| Currently, we have just upgraded our AIX OS to Version 4.3, running an
| Oracle 7.3.3 database, and we are having core dump file many times in
| a day.
| Has anyone out there face this problem before? Is upgrading of AIX
| will cause the core dump of oracle?
|
| In order to trace where the problem lies, we turn on the database
| tace, but
| we are having problem in interpreting the following trace file.
| I would very much appreciate if any of the oracle expert out there
| would
| like to help, thanks : )
|
| How do i interpret the following trace file? Is there a problem in it?
| And how to convert the "tim=69641995" into the actual date? Am I
| having
| any problem with the date configuration?
|
| Thanks in advance for taking your precious time in helping to looking
| into it : )
|
| rdgs,
| Brandon
|
| =====================
| PARSING IN CURSOR #10 len=49 dep=2 uid=11 oct=3 lid=11 tim=69641995
| hv=1258420735 ad='40c77e34'
| SELECT SWITCH_TYPE FROM LGW WHERE LGWIDX = :b1
| END OF STMT
| PARSE #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=69641995
| EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=69641995
| FETCH #10:c=0,e=0,p=0,cr=1,cu=2,mis=0,r=1,dep=2,og=4,tim=69641995
| EXEC #9:c=0,e=0,p=0,cr=1,cu=2,mis=0,r=1,dep=1,og=4,tim=69641995
| =====================
| PARSING IN CURSOR #11 len=51 dep=1 uid=11 oct=47 lid=11 tim=69641995
| hv=3947465601 ad='40c60058'
| begin :r:="NTMSRAW"."CBF"(:a1,:a2,:a3,:a4,:a5);end;
| END OF STMT
| PARSE #11:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69641995
| =====================
| PARSING IN CURSOR #12 len=49 dep=2 uid=11 oct=3 lid=11 tim=69641995
| hv=1258420735 ad='40c77e34'
| SELECT SWITCH_TYPE FROM LGW WHERE LGWIDX = :b1
| END OF STMT
| ..
| ..
| ..
| ..
|
| EXEC #6:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=69645349
| EXEC #7:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=69645349
| EXEC #8:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=69645349
| EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=69645349
| FETCH #10:c=0,e=0,p=0,cr=1,cu=2,mis=0,r=1
|
| Is there a problem when the trace file ends like last sentence above
| ??
|
| Thanks a lot for helping : )
Received on Sat May 25 2002 - 08:36:56 CDT