一次SQL诊断过程，大家帮忙分析下，诊断流程有问题么？
接到上司电话，告之系统有问题。一条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 539515085464
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以上。
页:
[1]