Re: negative elapsed times in 10046 trace file for single block reads
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: bdbafh@xxxxxxxxx
- Date: Wed, 20 Dec 2006 07:08:06 +0000
I've certainly run across cases where the ela= field was just plain wrong,
containing huge numbers and I think back in the early 9.2 days there were
times when the trace file got the timestamp number in the ela field. Don't
recall seeing negative figures though.
On 12/19/06, Paul Drake <bdbafh@xxxxxxxxx> wrote:
10g R1 std ed 32 bit (10.1.0.4 with cpuoct2006 applied).
w2k3 R2 sp1 32 bit
CPUs: a pair of dual core AMD Opterons
datafile storage is on a NetApp Filer attached by a pair of non-TOE
enabled onboard gigabit ethernet adapters using an MS iSCSI driver.
I'm seeing negative values for elapsed time in a 10046 trace file (lots of
them, actually):
WAIT #27: nam='db file sequential read' ela= 6652 p1=24 p2=52089 p3=1
WAIT #27: nam='db file sequential read' ela= -365131103 p1=25 p2=58558
p3=1
WAIT #27: nam='db file sequential read' ela= 15075 p1=25 p2=58560 p3=1
A quick search of metalink returned only the reference doc
*Note:39817.1 * *Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE
output*
Has anyone else run across this before?
thanks,
Paul
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
