ORACLE数据库事务恢复

 对于每个异常结束的进程或是系统意外停止，这时候磁盘上的数据文件和redo log上有可能存在未被提交的数据块
或是change vector,在数据库启动时，需要由smon进程进行事务恢复。单个用户只能回滚自己当前连接的事务，smon负
责恢复异常结束的事务
      default情况smon使用并行来执行事务恢复.参数fast_start_parallel_rollback 定义的rollback的并行进程数
default 为low(cpu*2),high(cpu*4),如果设置为false，表示禁用并行恢复，使用串行恢复。在一定的情况下，可能
会使用占用cpu很高,会出现smon占用cpu很高或是parallel slave占用cpu很高，在RAC下需要注意防止cpu过高导致
节点重启，保险起见可以改为false.对于跑了很大的job进程，需要特别小心.

    在v$fast_start_transactions和v$fast_start_serves中的两个视图中提供了当前正执行rollback的事务以及和
做了的块和评估的时间.
 创建一个表
  SQL> create table t1 as select * from dba_objects;
 
Table created

往这个表insert大量记录,不提交，然后手动kill掉该会话
declare
 i integer;
 begin
    for i in 1..1000
      loop
       insert into t1 select * from dba_objects nologging;
      end loop;
end;

SQL> select * from v$fast_start_transactions;
 
       USN        SLT        SEQ STATE            UNDOBLOCKSDONE UNDOBLOCKSTOTAL        PID    CPUTIME  PARENTUSN  PARENTSLT  PARENTSEQ XID              PXID             RCVSERVERS
---------- ---------- ---------- ---------------- -------------- --------------- ---------- ---------- ---------- ---------- ---------- ---------------- ---------------- ----------
         5          4       6706 RECOVERING                 3687            5748         19         42          0          0          0 05000400321A0000 0000000000000000         16
 
可以看到当前正在被回滚的事务，且数据启动很多parallel slave进程。

SQL> select round(undoblocksdone/cputime) "blocks per sec",cputime "used time",
  2  round(undoblockstotal/cputime) "total time"
  3  from v$fast_start_transactions
  4  where state='RECOVERING'
  5  ;
 
blocks per sec  used time total time
-------------- ---------- ----------
           185         61        339
对正在rollback的事务做一个评估,可以看到当前已经使用的时间或总的需要时间

      对于在数据库异常结束的时候的重启可以参看alert.log相关的smon启动事务恢复的日志.有时候对于undo表空间需要恢复的事务，但是undo表空间又已经不在了
所以会出问题，数据打不开hang住.，或是600(4193,4194)之类的错误,这种情况在实例意外中止或是停电的情况下特别容易发生，可以通过10513，level 2禁掉数据库进行transaction recovery。或是设置_smu_debug_mode=1024.这样可以临时打开数据库，删掉原来的undo,重新一个新的undo表空间.