10g新特性——回滾監視

在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欄位來獲得大概的剩餘時間，對於回滾操作也就是心中有數了。