ORACLE写日志过程存在缺陷

最新推荐文章于 2026-01-09 14:20:30 发布

转载最新推荐文章于 2026-01-09 14:20:30 发布 · 87 阅读

文章标签：

本文深入探讨了Oracle数据库中事务回滚的过程，包括日志的使用、块清除以及UNDO段头的事务状态修改。阐述了在特定情况下，如LGWR进程被挂起，事务虽然被正确回滚但未持久化到日志文件的现象，并解释了这种不一致读的原因及Oracle是如何解决这一问题的。

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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-717939/