SQL TRACE通过在会话级设置事件‘10046 trace name context level 12, forever’可以看到下面的跟踪信息。

    PARSING IN CURSOR #1 len=29 dep=0 uid=5 oct=3 lid=5 tim=1006862415399006 hv=4384
    51932 ad='84b05c04'
    select count(*) from tab, tab
    END OF STMT
    PARSE #1:c=10000,e=11334,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=4,tim=1006862415398976
    BINDS #1:
    EXEC #1:c=0,e=587,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1006862415399931
    WAIT #1: nam='SQL*Net message to client' ela= 10 p1=1650815232 p2=1 p3=0
    FETCH #1:c=2500000,e=2526458,p=0,cr=149542,cu=0,mis=0,r=1,dep=0,og=4,tim=1006862
    417926777
    WAIT #1: nam='SQL*Net message from client' ela= 1004 p1=1650815232 p2=1 p3=0
    FETCH #1:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1006862417928426
    WAIT #1: nam='SQL*Net message to client' ela= 7 p1=1650815232 p2=1 p3=0
    WAIT #1: nam='SQL*Net message from client' ela= 3636276 p1=1650815232 p2=1 p3=0

    注意：时间都是微妙级的，但是这里仍然有一些很有意思的地方：

    1. tim= 明显是微妙级的，这个tim 域给出了一个时间快照
    2. e= 和 ela= 也是微妙级的，这两个域表示持续的事件
    3. 比较有趣的是c=. 看上去好像是微妙级的，但是实际上是厘秒级的数据乘上了10000， 域c 表示cpu的消耗

    v$latch, / v$latch_parent / v$latch_children 的改变：

    在Oracle9i主要的改变是增加了wait_time字段。因此现在锁存器竞争更容易检测了，而在Oracle9i以前，只能通过察看sleeps次数来判断。在v$latch中主要相关的字段包括：

    V$LATCH

    NAMEVARCHAR(64)锁存器名称.
    SLEEPSNUMBER 锁存器由于忙而产生的sleep次数
    SLEEP1..11NUMBER显示了sleep的分布情况
    WAIT_TIME NUMBER微妙级的等待时间

    在Orace9i以前与v$latch的 ‘latch free’等待事件的SLEEPS字段对应的是v$system_event的TOTAL_WAITS字段：

    select event, total_waits, time_waited
    from v$system_event
    where event = 'latch free'

    select name, trunc(sleeps*100/ total, 2) "Perc of Sleeps"
    from v$latch, (select decode(sum(sleeps), 0, 1, sum(sleeps)) total from v$latch)
    where sleeps != 0

    有很多sleeps的锁存器会显示为v$system_event的大量等待时间。在Oracle9i由于在v$latch中有了WAIT_TIME字段，所以提供了更准确的信息：

    select name, trunc(wait_time*100/time_waited, 2) "Perc. of Time Waited"
    from v$latch, (select time_waited from v$system_event where event = 'latch free')
    where wait_time != 0
    order by 2

    还有那些没有改变?

    其他与时间相关的信息都没有改变。在V$SYSSTAT中象 ‘CPU used by this session’, ‘parse cpu time’ and ‘recursive cpu usage’等事件仍然表示为厘秒。Oracle没有改变这些统计信息的单位是因为这些信息可能会影响着一些依赖于他们的应用或者脚本。

    Oracle的Precise/Indepth在Oracle9i中由于使用了微妙做为单位，所以持续时间已经变得更加准确，但是仍然不能看到在一个特定的时间范围内的每个sql语句的资源消耗。了解每个sql语句的资源消耗能够帮助你确定那个sql语句是你首先应该调优的。 使用Oracle的Precise/Indepth，通过不断的监视Oracle的环境，收集用于性能分析的数据，就能够看到每条Sql语句的资源消耗情况。这些资源消耗情况最终被细分为：

    Using CPU
    CPU wait
    I/O wait
    Memory wait
    Other host wait
    Table lock wait
    Row lock wait
    Shared pool wait
    Buffer wait
    Rollback segment wait
    Redo log buffer wait
    Log switch and clear wait
    Internal lock wait
    Background process wait
    Parallel query sync. Wait
    Parallel query server wait
    Other wait