10g新特性——回滚监视

大家应该都有等女朋友的经历吧。想想下面两种情况哪种会更让你着急，一是知道她20分钟后肯定到，二是不确定到底她会什么时候来（可能5分钟，也可能50分钟）。我想对大部分人来说第二种会更让人发狂。[@more@]

在oracle的使用过程中，大家也一定会有下面的经历，先前执行了一个错误的大规模操作，幸好没有提交，现在需要做的回滚。等发出了rollback的命令后，迎接我们的是不可预知的等待，我们不知道到底现在回滚进行到了什么程度，大概还要需要多少才可能完成（这个更加值得关心）。也有很多人，经不这样的漫漫的折磨，把窗口关闭，进而导致更加严重的等待。

在10g之前，衡量回滚的过程可以通过查询v$transaction中的used_urec字段。这个字段表示特定使用使用回滚条目的数量，在insert等dml中对于回滚条目的需要一直在增加，当回滚的时候也是应该undo条目并释放undo条目的过程。所以在回滚的过程中这个字段的值代表着undo的进程。

SQL> create table sunwg as select *from dba_objects;

表已创建。

已用时间: 00: 00: 00.90

SQL> insert into sunwg select * from sunwg;

已创建50315行。

已用时间: 00: 00: 00.54

SQL> /

已创建100630行。

已用时间: 00: 00: 00.40

SQL> /

已创建201260行。

已用时间: 00: 00: 00.62

SQL> /

已创建402520行。

已用时间: 00: 00: 01.62

SQL> /

已创建805040行。

已用时间: 00: 00: 08.66

SQL> commit;

提交完成。

已用时间: 00: 00: 00.00

SQL> select count(*)from sunwg;

COUNT(*)

----------

1610080

已用时间: 00: 00: 02.76

这样我们就创建了一个有161W的一个测试表。现在我们进行delete操作，看一下v$transaction中的used_urec的变化。

SQL> delete from sunwg;

我们查询v$transaction可以看到used_urec的数值一直在增长，直到delete完成为止。接下来我们rollback看看。

SQL> rollback;

现在在查询v$transaction可以看到used_urec的数值一直在减少，直到回滚完后，used_urec变成0。

通过v$transaction可以了解整个回滚的过程，但是我们关系的回滚剩余时间的信息却很难从v$transaction中得到。这样视图v$session_longops就派上用场了。v$session_longops会记录系统中长时间运行的session信息，SOFAR 和TOTALWORK 提供操作的进展报告，字段time_remaining则表示该操作的剩余时间。在10g以前，回滚操作的系统是不会在v$session_longops中体现的，而在10g中则增加了Transaction Rollback的记录来表示回滚信息。

还是前面的例子

SQL> delete from sunwg;

SQL> rollback;

这个时候我们就可以查询v$session_longops的time_remaining字段来获得大概的剩余时间，对于回滚操作也就是心中有数了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8394333/viewspace-1000677/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8394333/viewspace-1000677/