Re: Same operation, more CPU time
- From: Paul Baumgartel <treegarden@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 5 May 2004 15:18:37 -0700 (PDT)
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@xxxxxxxxxxxxxxxxxx> 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.
>
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
