我的一个总结：检查点SCN深入研究(3)

最新推荐文章于 2017-12-06 16:05:20 发布

转载最新推荐文章于 2017-12-06 16:05:20 发布 · 153 阅读

本文探讨了Oracle数据库中日志切换与检查点的关系，特别是在DBWR尚未完成写操作时，是否会发生redo日志文件被覆盖的问题。通过实验验证，在特定情况下即使遇到意外断电，也不会导致数据丢失。

检查点发生时，出现日志切换，但是dbwr还没有写完，是否会覆盖redo log file，如果此时掉电，dbwr挂起，会出现丢失数据吗？

答：不会覆盖redo文件，要等待dbwr写完才覆盖。或者说要等待检查点完成才覆盖。

如果DBWn正在写的脏块是指对应到即将被覆盖的那个日志文件的，那么，因为在这些操作完成之前，不可能有覆盖这件事发生，假设你预料的掉电发生了，不会有什么问题，实例恢复时的前滚从刚才准备覆盖的那个日志文件开始。

如果正在写的脏块是指对应到刚刚被写满的那个日志文件的，肯定一时半会也写不完，日志切换也不会等它，如果切换成功后dbwr挂了，后面的写脏块操作估计也还没完成，但是，刚写满的那个文件并没有被覆盖，也不会有任何问题。

因此不会出现数据丢失！

当一个很大的dml发生时，用户在commit后，需要将redo log buffer中的脏数据写入redo log file中。如果在写的过程中，发现一个redo log file写不下的话，需要写另外一个redo log file，这时应该触发checkpoint，接着触发DBWn，将脏数据写入datafile，这时发生掉电，导致DBWR失败。这时其实就可以说commit失败了。以上所述其实就是commit没有提交成功。

www.ixdba.net

alter systen switch logfile会触发完全检查点;但是为什么，日志切换以后检查点只能记录到上一次归档日志产生的时间呢？而不是现在归档日志产生的时间呢？

因为这时的checkpoint enqueue队列中，也就是脏块队列中脏块还不够多，还不足以触发DBWn写脏块。所以，内存里需要写入的脏块所对应的redo还存在于上一个redo log里，这时你去看该redo log的status为active。

下面操作日志中出现当前redo log的status为current，而上一个redo log的status为active就说明了这一切。上一个redo log的status为active正是说明在上一个redo log中还存在未写入datafile的block所对应的redo。

SQL> create table gaojf8 as select * from all_objects;

Table created

SQL> insert into gaojf3 select * from gaojf3;

29630 rows inserted

SQL> /

59260 rows inserted

SQL> commit;

Commit complete

SQL> select * from x$kccrt;

ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS

-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------

421A54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 1 14 8796117861680 08/02/2006 02:29:36 0 13 cicro 08/02/2006 02:33:50

SQL> alter system switch logfile;

System altered

SQL> select * from x$kccrt;

ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS

421A54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 2 15 8796117861680 08/02/2006 02:29:36 0 14 cicro 08/02/2006 02:33:50

SQL> select * from x$kccrt;

ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS

421A54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 2 15 8796117861680 08/02/2006 02:29:36 0 14 cicro 08/02/2006 02:33:50

SQL> select * from x$kccrt;

ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS

IXDBA.NET社区论坛

421A54D0 0 1 1 15 8796119128114 08/08/2006 00:35:51 1 15 2 16 0200000000000000 0 0 3 1 3 3 16 8796117861680 08/02/2006 02:29:36 0 15 cicro 08/02/2006 02:33:50

从上面试验中可以看到，完全检查点正在执行，还没有执行完毕。因此，切换日志前后察看x$kccrt，看到的RTCKP_SCN, RTCKP_TIM没有发生变化。等检查点执行完毕后（也就是检查点触发的dbwr执行完写操作后），rtckp_scn, rtckp_tim才发生变化。