今天看到一个关于如何监控长操作的文档,这里简单记录一下要点。
一、什么情况下,操作信息会出现在V$SESSION_LONGOPS
同时满足以下几个条件,操作信息才会出现在V$SESSION_LONGOPS中。
1、操作是以下几种操作之一
# Table scan;
# Index Fast Full Scan;
# Hash join;
# Sort/Merge;
# Sort Output;
# Rollback;
# Gather Table's Index Statistics
不同的版本下V$SESSION_LONGOPS记录的操作可能会不一样。
2、操作时间大于6秒
3、读取的block数目大于一定量
1)如果是TABLE FULL SCAN,读取的block数目至少大于10000
2)如果是Index Fast Full Scan,读取的block数目至少大于1000
3)其他操作读取block的数目不明
二、如何监控耗时长的操作
举例说明。
会话1:发出查询
suk@SUK> select * from t2;
已选择826112行。
已用时间: 00: 00: 29.89
执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=123 Card=103264 Byte
s=8880704)
1 0 TABLE ACCESS (FULL) OF 'T2' (Cost=123 Card=103264 Bytes=88
80704)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
64505 consistent gets
0 physical reads
会话2:在会话1查询过后一小段时间后(大于6s),查询V$SESSION_LONGOPS视图
SQL> SELECT SE.SID,
2 OPNAME,
3 TRUNC(SOFAR / TOTALWORK * 100, 2) || '%' AS PCT_WORK,
4 ELAPSED_SECONDS ELAPSED,
5 ROUND(ELAPSED_SECONDS * (TOTALWORK - SOFAR) / SOFAR) REMAIN_TIME,
6 SQL_TEXT
7 FROM V$SESSION_LONGOPS SL, V$SQLAREA SA, V$SESSION SE
8 WHERE SL.SQL_HASH_VALUE = SA.HASH_VALUE
9 AND SL.SID = SE.SID
10 AND SOFAR != TOTALWORK
11 ORDER BY START_TIME
12 ;
SID OPNAME PCT_WORK ELAPSED REMAIN_TIME SQL_TEXT
---------- ----------------------------- ------------ ---------- ----------- --------------------------------------------------
10 Table Scan 67.07% 21 10 select * from t2
会话1的真实执行时间:29.89s
会话2从V$SESSION_LONGOPS的估算时间:21 + 10 = 31s
可以看到,时间执行和估算的有误差,但是大体是正确的。
在实际中,你可能通过这个查询估算到某个SQL执行的剩余时间很短了,但实际上操作过了很久才结束。
这是因为V$SESSION_LONGOPS只记录部分操作的信息,但是一个SQL可能会包含很多个操作步骤,V$SESSION_LONGOPS记录的只是这个SQL要执行众多操作的一步。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/231499/viewspace-63841/,如需转载,请注明出处,否则将追究法律责任。