Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Same operation, more CPU time
Thanks, Jonathan--good point regarding visits to undo blocks showing up
in the "query" column. I'll take another look at consistent gets per
row fetched in both cases.
Spinning for latches might make sense as well...there are more latch waits in the concurrent case than in the GUI-only case.
In any event, would you agree that nothing much can be done about performance degradation when additional time is attributable principally to more CPU usage? Would you further agree that I should mumble and wave my hands when explaining this to management? ;-)
PB
--- Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> I think if you had to do more work in creating
> read consistent blocks, the trace file would show
> the access to the undo blocks as part of the "query"
> column, which you would have noticed.
>
> If you are busy updating, then perhaps you have
> extra competition for latches, so you may be
> expending extra CPU spinning for latches, and
> being pushed off the run queue etc. Whilst the
> apparent difference in time might then seem
> unreasonable for the likely effects, it is possible
> that the actual difference in time is small, but the
> increment is enough to allow what Cary calls
> (something like) "quantization" errors to become
> exaggerated.
>
> You may also have effects like processes yielding,
> but staying runnable when not competing, whereas
> they may have to sleep when competing - and this
> could affect the CPU - please note that I am hand-waving
> and mumbling when I say this.
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Wed May 05 2004 - 17:17:48 CDT
![]() |
![]() |