On May 5, 10:13=A0am, "jshen....@[EMAIL PROTECTED]
" <jshen....@[EMAIL PROTECTED]
> wrote:
> Hi,
>
> =A0 =A0two of our DB server suffered very high CPU load today. we could
> not identify the exact reason
> for it.
>
> =A0 =A0We run a main DB whose table content update frequently. =A0Both
of
> the two questionable servers maintein Snapshot of =A0main DB, =A0they
> refresh snapshot every 5 min. The OS of two stallite server is HP UX
> 11i. =A0Normally, the two stalitte servers' CPU is just around 20%.
>
> =A0 =A0Today, =A0both of them run suffered very high CPU load (around
96%
> and above), application on stalite DB respond very slow with a lot of
> service timeout. =A0we have to stop the application =A0which make the
two
> stallite DB CPU come back within 20min. Restarting application does
> not generate the same problem at all.
>
> =A0 =A0Looking into sar ball stored, we just find there is high CPU and
a
> lot of semops. But there is NO alert.log record and Archive was
> executed successfully.
>
> =A0 =A0What's the possible reason for this ?
>
> =A0 =A0sar record information:
>
This is only half of it. You need to ask Oracle what it thinks it is
waiting for. It could be something simple, or something convoluted
like a problem with your I/O that makes the Oracle concurrency methods
spin the cpu. See the performance manual at tahiti.oracle.com, as
well as the book by Cary Milsap. Of course, being on such an old
Oracle it could be something that is easily solved with the more
modern way things are done nowadays, but not so easy the old ways.
Two things you might do, run statspacks (described in the docs), and
check how many extents are in your FET$ table (google for scripts).
jg
--
@[EMAIL PROTECTED]
is bogus.
Cinco de Mayo!
|
