接到上司电话，告之系统有问题。一条10万级别的语句汇总在RAC上，灰常之慢。
看了下日志 发现最小也要10分钟。赶紧查看SQL文本与执行计划

可惜的是我得到通知的时候，已经过了十多个小时了。执行计划早已经被冲出library cache
文本和语句都查不到了。

没执行计划还玩啥啊。当然我也不会等到执行的时候做跟踪。这些的话要后半夜做，而且是第二天了。
既然不给看执行计划，那就看看有什么等待事件吧。

查看一下动态视图 v$active_session_history
还好日志有程序的执行时间，使用字段 SAMPLE_TIME 采样时间来查找程序执行时间内的所有等待事件。

然后分类进行汇总

SELECT wait_class,t.event,COUNT(*),sum(t.time_waited)
FROM ACTIVE_SESSION_HISTORY t
WHERE t.session_state='WAITING'
GROUP BY wait_class,event



WAIT_CLASS    EVENT      COUNT(*)         SUM(T.TIME_WAITED)
User I/O   db file sequential read     23     427561
System I/O       control file sequential read      18     15162
Cluster     gc current grant 2-way    2       3202
Cluster     gc current grant busy      1       133469
Cluster     gc current block 2-way    3       2049
Cluster     gc current block 3-way    1       1417
Cluster     gc cr block 2-way     1       891
Cluster     gc cr block busy        3       69573
Concurrency    row cache lock          539  515085464
User I/O   db file scattered read      6       151364
Cluster     gc cr multi block request 6       1219176

发现 row cache lock 非常的大515085464微秒。

换算一下
SELECT 515085464/1000000/60
FROM dual

用于等待序列申请所用时间 8.58475773333333分


发现该程序引用的序列为nocache。

还是要再次监控下，由于该序列专属该程序调用。所以建议加大CACHE值。

目前还需要再次监控几天，已确定是否真为SEQUENCE CACHE属性造成。

如果是Oracle 10g以上的版本，我们可以采用dbms_xplan.display_awr找到这个sql 语句的执行计划，一般可以找到。
或者使用explain plan for的方式，不会实际执行sql语句，只是得到sql的执行计划。

如果要看等待事件，最好是v$system_event或者v$session_event。

另外，如果你想得到sql_id，你可以查询dba_hist_sql视图。
当然前提是10g以上。