Re: Wait analysis

Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:
>But I don't think it adds much value other
>than as a rough guideline to indicate that
>there is a significant contention problem
>and some scope for improvement. In fact,
>unless the batch jobs are identical, on
>virtually identical data sets, it might be
>very misleading to average things out
>like this instead of drilling into a
>v$session_event snapshot to see if
>that categorises waits by batch task.

That there's a problem is fairly obvious, I'm trying to quantify it to compare with other runs. The processes are identical and the workloads are sufficiently identical.

Thanks for your comments, I won't place much value on the actual figures.

>Also, with 96 active processes, the
>number of CPUs, hence length of the
>run queues, are also important factors
>to consider - some, if not quite a lot,
>of that wait time could be time spent
>runnable but not running.

This was a 64 CPU system, given that either a batch process or its Oracle shadow process at any given moment, never both, the run queue shouldn't have got longer than 1.5. A small overloading allows the CPU to do useful work while one session is blocked on IO.

Am I correct in thinking that where ever possible, Oracle avoids doing anything that'll get a process descheduled while holding a latch, for example, IO?

-- 
Andrew Mobbs - http://www.chiark.greenend.org.uk/~andrewm/