v$session_longops,这是个很有用的视图,记录了运行时间超过6秒的视图,常用来追踪有问题的sql和估算语句执行的剩余时间。
先看下官方说明:
V$SESSION_LONGOPS
displays the status of various operations that run for longer than 6 seconds (in absolute time). These operations currently include many backup and recovery functions, statistics gathering, and query execution, and more operations are added for every Oracle release.
To monitor query execution progress, you must be using the cost-based optimizer and you must:
-
Set the
TIMED_STATISTICS
orSQL_TRACE
parameters totrue
-
Gather statistics for your objects with the
ANALYZE
statement or theDBMS_STATS
package
1. 参数timed_statistics或sql_trace必须至少有个是true
2. 必须用dbms_stats包分析表或其他对象
来试试吧:
SQL> show parameter sql_trace
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sql_trace boolean FALSE
SQL> show parameter timed_statistics
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
timed_statistics boolean TRUE
timed_statistics 为true,表示可以用这个功能,然后再分析下表:
BEGIN
dbms_stats.gather_table_stats('ORACLE','TEST2',cascade => TRUE);
END;
1. 先试试操作剩余时间:
CREATE INDEX idx1 ON test2(object_id);
可以看到创建索引大概还需要476秒,总共的工作量为87220数据块,已完成24029个数据块
如果你是用并行度进行DML操作,会发现每个执行session在v$session_longops中的行数,越来越多,也就是说调度进程是不断给执行进程分配任务的。
而通讯进程虽然是长时间执行,但在v$session_longops视图中是查不到记录的。
2. 试试回滚操作剩余时间:
SQL> select * from v$mystat where rownum=1;
SID STATISTIC# VALUE
---------- ---------- ----------
159 0 1
SQL> DELETE FROM test2 WHERE object_id<100;
98000 rows deleted.
SQL> rollback;
看回滚进度
关于回滚进度的查询,这里要特别指出几点:
1. 中断操作(如关闭窗口,点击developer的闪电)所做的回滚动作时不会出现在这个视图中;
2. 点击developer上面的回滚按钮,所进行的回滚,也在这个视图中查不到;
3. 用并行度更新后,rollback也在这个视图中查不到,只能用session中(此时的session对应的sql_id为空,DML操作时用了几个并行度就会生成同样数量的回滚session,还有在session中会显示之前你并行更新的主session正在被回滚session阻塞)taddr去v$trasaction中去观察其used_ublk的变化速度来估算回滚进度。