ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORACLE写日志过程存在缺陷

ORACLE写日志过程存在缺陷

原创 Linux操作系统 作者:wei-xh 时间:2012-03-07 14:21:27 0 删除 编辑

CODE:

Session 1


create table t1(n1 number);
insert into t1 values(1);
commit;

session 2 (sysdba)


oradebug setorapid 12(LGWR的进程)
oradebug suspend

session 1


update t1 set n1 = 2;
commit; 会话被hang住了

session 3


select n1 from smart.t1;

N1
----------
2很惊奇,我们看到的是2.commit在发出后,ORACLE需要做块清除,UNDO段头的块清除,数据块的块清除,但是数据块的清除一般是延迟块清除。而UNDO块头无论如何,是要清除的,就像我们知道的,需要把UNDO段头的事务槽的事务活动状态修改为9,修改提交SCN等。这些清除也是要产生REDO的,这些REDO会随着事务的日志刷新LOG BUFFER里。这些日志被刷新到LOG BUFFER后,由于LGWR被我们挂起来了,导致写不到LOGFILE里。可是无论如何回滚段头的事务槽已经做了清除,代表事务已经终结。这个时候,一个读进程读取数据块,虽然很大可能由于延迟块清除导致数据块的事务信息没被清理,可是在参照回滚段头后,发现这个事务已经提交了。虽然这个提交没被持久化进LOGFILE里。在某些情况下,比如空间不足,导致切换日志切换不下去,或者在做日志切换时候,切换比较久,就可能会导致产生这种不一致的读。   我们重启实例后,再看。

CODE:

session 3 select n1 from smart.t1;
N1
----------
1ORACLE已经对上面的事务成功回滚了 ORACLE为什么能在这个情况下进行回滚呢?同事提出了一个问题,如果这个时候UNDO段头对应的脏快已经被刷入到磁盘了怎么办?我们知道前滚的时候,是需要在旧的数据块上应用新日志来达到目的,但是万一脏数据块已经被刷新到了磁盘,也就是事务提交信息已经被写入到了磁盘,由于日志没被写进LOG FILE,那么这个事务其实是没法回滚了。LEWIS告诉了我们答案:One of the most important features of the Oracle code is that the database writer will not write a
changed block to disk before the log writer has written the redo that describes how the block was changed.
也就是说,日志不写入LOG FILE,对应的脏快是不会提前写进去。   

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22034023/viewspace-717939/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE组成员,DBGeeK用户组发起人。曾在DTCC、ORACLE技术嘉年华、Gdevops等公开场合做过数据库技术专题分享,2017年应Oracle邀请在世界最大的数据库会议OOW上做技术分享。组织翻译了《拨云见日,解密Oracle ASM内核》一书。

注册时间:2009-07-04

  • 博文量
    422
  • 访问量
    2306678