10g新特性——回滚监视

大家应该都有等女朋友的经历吧。想想下面两种情况哪种会更让你着急，一是知道她20分钟后肯定到，二是不确定到底她会什么时候来（可能5分钟，也可能50分钟）。我想对大部分人来说第二种会更让人发狂。
在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字段来获得大概的剩余时间，对于回滚操作也就是心中有数了。