全部博文(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表空间.