RE: Low CPU time, no Wait time but high elapsed time
- From: <rajendra.pande@xxxxxxx>
- To: <exriscer@xxxxxxxxx>, <toon.koppelaars@xxxxxxxxxxx>
- Date: Fri, 5 Aug 2011 07:39:06 -0400
I did not think LPAR was managed in a similar manner like a VM.
My understanding was that in a LPAR the resources are hard bound when
the LPAR gets created
You can move them around later but still this is not the same as a
hypervisor.
Once moved the resources stay with the new LPAR - but I am not sure.
Maybe the newer LPARs are hypervised.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of LS Cheng
Sent: Friday, August 05, 2011 3:17 AM
To: Toon Koppelaars
Cc: Oracle Mailinglist
Subject: Re: Low CPU time, no Wait time but high elapsed time
aha so this might mean the box was saturated and the LPAR couldnt get
CPU fast enough?
Thanks
On Fri, Aug 5, 2011 at 8:07 AM, Toon Koppelaars
<toon.koppelaars@xxxxxxxxxxx> wrote:
That could explain it. I have had experiences where a trace-file of a
slow session did not record any waittime with similar observation like
yours.
This was due to the fact that the 'slow session' was running inside a VM
that did not get a lot of cpu-cycles allocated from the VM manager.
On Fri, Aug 5, 2011 at 7:45 AM, LS Cheng <exriscer@xxxxxxxxx> wrote:
The catalog database runs in side an IBM P780 Logical Partition (LPAR)
Thanks
On Fri, Aug 5, 2011 at 7:42 AM, Toon Koppelaars
<toon.koppelaars@xxxxxxxxxxx> wrote:
Is this a virtualized environment?
On Fri, Aug 5, 2011 at 7:38 AM, LS Cheng <exriscer@xxxxxxxxx> wrote:
Hi
The other day while I was troubleshooting with 10046 some RMAN resync
issues with the catalog (was taking very long time) I noticed that
insert and update statements were taking extremely long time, one second
per execution more or less. The 10046 trace for the RMAN catalog
database session showed cpu time 10000 microseconds, no waits and
elapsed around 1200000 microseconds. This is 10.2.0.5 running on AIX.
I did some research and couldnt find any good reason.
Anyone come across with this sort of issue?
Thanks!
--
LSC
--
Toon Koppelaars
RuleGen BV
Toon.Koppelaars@xxxxxxxxxxx
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com
(co)Author: "Applied Mathematics for Database Professionals"
www.rulegen.com/am4dp-backcover-text
--
Toon Koppelaars
RuleGen BV
Toon.Koppelaars@xxxxxxxxxxx
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com
(co)Author: "Applied Mathematics for Database Professionals"
www.rulegen.com/am4dp-backcover-text
Please visit our website at
http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other
personal information.
Other related posts:
