Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2796814
  • 博文数量: 389
  • 博客积分: 4177
  • 博客等级: 上校
  • 技术积分: 4773
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-16 23:29
文章分类

全部博文(389)

分类: Oracle

2013-09-01 22:38:21

                                                             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表空间.

阅读(4933) | 评论(1) | 转发(1) |
给主人留下些什么吧!~~

xiaojilidz2013-09-02 19:10:33

好文章  学习了!