Re: Oracle goes ballistic

"Wombat" <Wombat_at_Wombat.co.uk> wrote in message news:<9q4uog$c6n$1_at_newsg2.svr.pol.co.uk>...
> Thanks, will take a look. The overhead problem was one thing we were
> worried about if we were to start tracing etc!
>
> Incidentally, the process which uses the CPU is called oraclelims ( our
> database is called lims). Looking at the system today we have three of
> these running so I will check out the changes when the runaway occurs.
>
> We have very few users, 512 meg of ram 1 gig swap and plenty of free disk
> space. The system is running smoothly apart from this odd glitch.
>
> Thanks again
>
> WB

Hmmm, I wonder if that is a commercial package that I saw once with the same name. It had the same problem, turned out to be something like an otrace bug (on 7.3.4, look for files like .../otrace/admin/*.dat) or an import of data from another system turned on the optimizer incorrectly 'cause of OPTIMIZER_MODE=CHOOSE.
>
> Trust me to get a darn tigger in the thread!
>
> Ricky Sanchez <rsanchez_at_more.net> wrote in message
> news:3BC5F6CF.BCB2D85C_at_more.net...
> > Install Statspack and run snaps at perhaps five minute intervals until
> > you capture the "slow" period. You can get the 8.1.6 version of
> > Statspack and retrofit it to 8.0.x with an included script to create a
> > view of the multiple buffer pools. Put Statspack in its own tablespace,
> > or a tools tablespace with its own disk so you don't induce contention
> > while running snapshots. Statspack has otherwise insignificant overhead.
> >
> > Also, get concurrent sar reports for that same period to make sure the
> > box and operating system are healthy enough. Make sure you get memory,
> > cpu and I/O info from sar for that period.
> >
> > You can use cron to kick off the snaps and the sar, which makes it easy
> > to synchronize the two and to turn them back off again. Once you are
> > past this issue, 1/2 hour snaps on an ongoing basis are excellent for
> > continuing monitoring, but for diagnostics use the shorter interval to
> > "zoom" in on the problem.
> >
> > Do five minute snaps until you have the problem period covered, then run
> > a report for that five or ten minute period to see exactly what is going
> > on. If you don't know how to interpret the thing, post it here and I
> > will take a look at it, as will others. You can also upload it to the
> > Oraperf site if it is running that day.
> >
> > - ricky

jg

--
See your database administrator?  Who does this #@$%@! message think
is going to read it?