利用v$session_longops监控长操作

今天看到一个关于如何监控长操作的文档，这里简单记录一下要点。

一、什么情况下，操作信息会出现在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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/231499/viewspace-63841/