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