Comments embedded
Regards
--
Sybrand Bakker
Senior Oracle DBA
to reply remove '-verwijderdit' from my e-mail address
"Alun Liggins" <a.liggins_at_btinternet.com> wrote in message
news:acqg2n$pbl$1_at_knossos.btinternet.com...
> Hmmmm....
>
> 0) What does the alert log say? Have you called it in to Oracle? Check
on
> metalink, but I recommend you log a call with
> Oracle as well. You will need to send oracle your alert.log file
>
> 1) The libraries on AIX may have been upgraded, resulting in Oracle
getting
> confused about them and dumping.
> Do you need to relink the oracle binaries? I suspect you may need to
> (consult documentation or Oracle support)
> Did you change anything on the oracle side when you upgraded? Remember to
> take backups of everything (cold backups)
> before you start tinkering/upgrading.... What oslevel did you upgrade
from?
>
if he upgraded the O/S he simply *HAS* to relink Oracle.
I suspect however he will run into compatibility issues, as 4.3 didn't exist
yet when 7.3.3 hit the market
> 2) 7.3.3 is a bit old, you may need to patch it to 7.3.4 (follow the
upgrade
> instructions). (Note that support for 7.3.3
> is getting less and less popular nowadays as Oracle are more bloated
> versions.).
Support for 7.3.3 has stopped in the previous century. PERIOD.
What you call 'bloated' is a lot of useful features many would be dying to
have in the 7 era.
But of course everyone is free to continue to run desupported software.
>
> 3) the database trace stuff may not be much help till you've investigated
> the about steps
>
> Alun
>
>
> "Brandon" <brandon_oh_at_yahoo.com> wrote in message
> news: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 Sun May 26 2002 - 07:24:01 CDT
