OK, now I can see that you are indeed reading V$SESSION_WAIT from another
session. I can also see the time jumps shown by V$TIMER. Note that V$TIMER does
not change at all over several non-trivial waits, and then catches up a big
chunk. This reflects the fact that calls to V$TIMER are reading an SGA data
structure. You only see a change in V$TIMER when Oracle updates that data
structure, not when the time changes.

PS: This V$TIMER implementation appears to be specific to Solaris under Oracle8i.

However, you have a much bigger problem here as shown by the long delays in the
10046 trace. For example, block (7,32780) took 1.89 seconds to read! Something
is giving you VERY inconsistent I/O performance. It looks like you are either
heavily CPU bound, or paging, or may have a faulty disk.


-----Original Message-----
Sent: Tuesday, 29 August 2000 5:13


I did a trace and ran my code at the same time.  In my code, I printed
v$timer.hsecs, v$session_wait.p1 and p2 and seqno. As you can see in file xyzzz,
for block 32787, there appears to be a problem with v$timer.  I am looking into
using an OS low-level timer.


-----Original Message-----
Sent: Monday, August 28, 2000 1:01 PM


You cannot afford to query V$SESSION_WAIT from the same session. It will distort
the numbers dramatically. If you really want to do that, you should do it from
another session.

DBMS_UTILITY.GET_TIME returns centiseconds. To time something, you call it
before and after and take the difference as the elapsed time.


-----Original Message-----
Sent: Tuesday, 29 August 2000 3:41


If I used DBMS_UTILITY.GET_TIME in my code, how can I get the time when I make
the query to v$session_wait?  What are the units for DBMS_UTILITY.GET_TIME?


-----Original Message-----
Sent: Monday, August 28, 2000 12:39 PM


Code based timing is always going to overstate things. The times contained in
the trace files are MUCH better. If you do want to measure elapsed time in your
code, then may I suggest that you use DBMS_UTILITY.GET_TIME instead. That has
much less overhead than querying V$TIMER and so will give more accurate results.

Incidentally, 0.78 seconds for a single block read is certainly not a time that
I would be satisfied with either, much less 2.15 seconds!


-----Original Message-----
Sent: Monday, 28 August 2000 22:19


Thanks, Steve.  As you know, my program is querying the v$session_wait for
events related to reads and writes on the data files.  When I do a trace on
a session that I have a SQL running, and at the same time run my code, I
observe the following behaviour:  I get the longest waits in my code, while
the trace shows many short waits. (For my purposes, I think this is OK).
The other thing is that I am using v$timer, to measure the time that is
related to a particular event.  This isn't giving me a time that I am
satisfied with.  For example, the trace will show that I was 'dbfile
sequential read' on file 7 block 33900 for 78/100 sec.  My code shows the
same file and block, but it will show 2.15 seconds.  I am trying to only do
what is necessary in the tight loop that queries v$session_wait.  Do you
have any suggestions how to fix this?  I really appreciate all of your help.