时间模型

    刚刚给Bill解释完他的初步发现，Lora就走了进来，也带着类似的抱怨：她的SID 355会话非常慢。 John又一次通过对V$SESSION视图执行下面的查询来寻找该会话等待的事件：

    select event, seconds_in_wait,
    wait_time
    from v$session
    where sid = 355;

    输出结果显示Lora的会话中有各种各样的等待事件，包括栓（latch）争用，它表明一个应用程序的设计可能有问题。但是，John在给Lora提供修改应用程序的方法之前，他必须用事实来支持他的理论，即该应用程序设计的不好导致了Lora的会话性能低下。为了测试他的理论，他决定要确定Lora会话对资源的利用是否格外高，以及除了这个会话以外其他会话的速度是否也很慢。

    在Oracle数据库10g的Time Model（时间模型）界面中，John可以轻松查看在各种活动中会话所用时间的详细情况。他对V$SESS_TIME_MODEL视图执行下面的查询语句：

    select stat_name, value
    from v$sess_time_model
    where sid = 355;

    给出的输出结果显示了该会话在各个方面所花费的时间（单位：微秒）。从这个结果中John了解到，执行所有SQL查询共花878088366微秒（执行），其中503996336微秒用于解析（解析花费的时间），即占了SQL执行时间的57%，这表明导致速度慢的原因是解析操作过多。John告诉Lora这一信息，她采纳了应用程序设计小组的建议。

    OS统计数据

    在仔细检查用户的性能问题时，John还需要排除主机系统是瓶颈的可能性。在采用Oracle 10g以前，他可以使用操作系统（OS）工具，如sar 和vmstat，并推断出一些确定争用问题的度量指标。在Oracle 10g中，在数据库中自动采集OS级别的度量指标。为了查看潜在的主机争用问题，John对V$OSSTAT视图执行下面的查询：

    select * from v$osstat;

    给出的输出结果显示了所采集的OS级别的各种度量指标元素。所有时间元素都以厘秒为单位。从代码清单6显示的结果中John了解到，系统的一个CPU有51025805厘秒空闲（IDLE_TICKS）、2389857厘秒繁忙（BUSY_TICKS），这表明CPU有大约4%的时间繁忙。从中他得出结论，在主机中CPU不是瓶颈。请注意，如果主机系统有多于1个的CPU，则标头中有AVG_前缀的列，如AVG_IDLE_TICKS将显示所有CPU的这些度量指标的平均值。

    活动会话的历史

    到目前为止，每当发生问题时用户就向John咨询，使他能实时地查看性能状况。没过多久Janice又找到John，抱怨最近出现的性能问题。当John查询V$SESSION视图时，会话是空闲的，没有正在等待的事件。John如何检查Janice的会话出现问题时正在等待什么事件呢？

    Oracle 10g在内存缓冲区内每秒采集一次活动会话的信息。这个缓冲区被称为活动会话历史（Active Session History，ASH），可以在V$ACTIVE_SESSION_HISTORY动态性能视图中查看它，其中的数据在被新数据周期性地覆盖前保留30分钟。John得到Janice会话的SID和SERIAL#，然后对V$ACTIVE_SESSION_HISTORY视图执行以下查询，以便找出会话过去等待的事件。

    select sample_time, event, wait_time
    from v$active_session_history
    where session_id = 271
    and session_serial# = 5;

    输出结果显示了几条重要信息。首先它显示SAMPLE_TIME--显示统计数字采集的时间--使John能够将出现的性能问题与等待事件联系起来。利用V$ACTIVE_SESSION_HISTORY视图中的数据，John看到大约下午3:17，该会话等待了几次日志缓冲空间事件，这表明重做日志缓冲出了问题。为了进一步诊断，John用下面对V$SQL视图执行的查询来确定当时由该会话执行的确切SQL语句：

    select sql_text, application_wait_time
    from v$sql
    where sql_id in (
    select sql_id
    from v$active_session_history
    where sample_time =
    '22-FEB-04 03.17.31.188 PM'
    and session_id = 271
    and session_serial# = 5
    );

    APPLICATION_WAIT_TIME列显示执行该SQL的会话等待了多长时间的application等待类。除了SQL_ID，V$ACTIVE_SESSION_HISTORY视图还使John了解了被等待的具体行（在锁争用的情况下）、客户端标识符以及其它信息。

    如果用户晚一点儿找John，视图中的数据已经被覆盖了，那该怎么办呢？当数据从这个动态性能视图中清除时，这些数据被送到活动工作负载信息库（Active Workload Repository，AWR）中，它是一个基于磁盘的信息库。被清除的ASH（活动会话历史）数据可以在DBA_HIST_ACTIVE_SESSION_HIST视图中看到，这使John能够看到过去的会话的等待事件。在默认状态下，AWR中的数据7天后即被清除。

    结论

    Oracle数据库10g引入了许多增强特性，它们是为了简化性能诊断过程并使其自动化而设计的。Oracle数据库10g的等待事件信息是经过精心设计的，从而提供了对问题起因的更加深入的洞察力，这使得在大多数情况下，特别是在主动性能调优时诊断性能问题轻而易举。