请问oracle如何判断redo保护的数据已经全被写到磁盘?

lghwf

a filled online redo log file is available after the changes recorded in it have
been checkpointed (written) to disk by database writer (DBWn).
那么ORACLE 如何判断 这些数据已经被写入到数据库中去了呢？
越想越迷糊

Maclean Liu(刘相兵

"Checkpoint  complete完成后，CKPT 更新控制文件，此时的GROUP #1 状态变为INACTIVE,ORACLE 就是根据这个状态来判断 相关的数据已经写到 数据库中去了吧。"



说反了 ，  Checkpoint  complete完成 就保证了 dirty buffer 已经写到 Disk 上去了 ，

logfile switch checkpoint complete完成 ，说明active redo log 相关的dirty buffer已经被写出到Disk ，从而  active redo log 的状态 变成 inactive ，  inactive 的 联机日志 可以被覆盖 allocate new sequence 。



不是  active redo log 的状态 变成 inactive 说明 active redo log 相关的dirty buffer已经被写出到Disk ，这样说 因果颠倒了！ --misunderstand

lghwf

谢谢 Maclean！
Checkpoint  complete完成后，CKPT 更新控制文件，此时的GROUP #1 状态变为INACTIVE,ORACLE 就是根据这个状态来判断 相关的数据已经写到 数据库中去了吧。判断GROUP # 的状态是根据控制文件里的信息来判断其状态是INACTIVE还是ACTIVE的，不知我这么理解是否正确？
       因为我刚做了个实验，做了一个数据比较多的DML，COMMIT之后，发现两个 REDO LOG GROUP的状态时ACTIVESQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1          1       4042   52428800          1 YES      ACTIVE                14270778 2012/3/9 19
         2          1       4043   52428800          1 YES      ACTIVE                14271180 2012/3/9 19
         3          1       4044   52428800          1 NO       CURRENT               14271570 2012/3/9 19

SQL> set time on
19:38:30 SQL> set time on
19:38:31 SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1          1       4042   52428800          1 YES      ACTIVE                14270778 2012/3/9 19
         2          1       4043   52428800          1 YES      ACTIVE                14271180 2012/3/9 19
         3          1       4044   52428800          1 NO       CURRENT               14271570 2012/3/9 19

, 过了一会儿，都变成了INACTIVE

19:38:33 SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1          1       4042   52428800          1 YES      INACTIVE              14270778 2012/3/9 19
         2          1       4043   52428800          1 YES      INACTIVE              14271180 2012/3/9 19
         3          1       4044   52428800          1 NO       CURRENT               14271570 2012/3/9 19

对应的文件 最后修改时间并没有变
[localhost.localdomain]:[/oradata/test1]$ ls -l
total 38671504
-rw-r----- 1 oracle dba    14008320 Mar  9 19:40 control01.ctl
-rw-r----- 1 oracle dba    14008320 Mar  9 19:40 control02.ctl
-rw-r----- 1 oracle dba    14008320 Mar  9 19:40 control03.ctl
-rw-r----- 1 oracle dba    52429312 Mar  9 19:34 redo01.log
-rw-r----- 1 oracle dba    52429312 Mar  9 19:34 redo02.log
-rw-r----- 1 oracle dba    52429312 Mar  9 19:40 redo03.log
-rw-r----- 1 oracle dba 12383690752 Mar  9 19:39 sysaux01.dbf
-rw-r----- 1 oracle dba   482353152 Mar  9 19:39 system01.dbf
-rw-r----- 1 oracle dba   245374976 Mar  8 22:00 temp01.dbf
-rw-r----- 1 oracle dba 10978598912 Mar  9 19:40 undotbs01.dbf
-rw-r----- 1 oracle dba 15272517632 Mar  9 19:39 users01.dbf


  有关的知识 不知哪个文档里 讲的比较细致，我翻了翻CONCEPT和ADMINISTRATOR GUIDE ，也没有发现这方面的详细介绍。

[ 本帖最后由 lghwf 于 2012-3-9 20:12 编辑 ]

Maclean Liu(刘相兵

a filled online redo log file is available after the changes recorded in it have been checkpointed (written) to disk by database writer (DBWn).

它的意思其实是  一个已填充的(或者说已切换过的) 重做日志 在 其 变化记录相关的dirty buffer在 被DBWR写入(写入的原因未必是 checkpoint) 磁盘之前始终 不会被覆盖， available 存在可用。

为什么要这样？ 因为：
在非归档模式下  若该 active logfile中的日志被覆盖 而其 变化记录相关的dirty buffer未被写入磁盘，那么若此时instance crash 就无法完成前滚

若在归档模式下， 该active logfile中的日志被归档了，  而其 变化记录相关的dirty buffer未被写入磁盘， 那么此时instance crash 则需要 使用到 归档日志  ， 使用归档日志的恢复 recovery 是 介质恢复media recovery， 这是不被允许的。

所以在这2种模式下， 在变化记录相关的dirty buffer未被写入磁盘前， logfile 处于active 模式下 不会被覆盖。


那么ORACLE 如何判断 这些数据已经被写入到数据库中去了呢？

日志切换是会引发 Log Switch Checkpoint的， 在8i以前 Log Switch Checkpoint是 FULL CHECKPOINT完全检查点.

在 8i以后Log Switch Checkpoint 会要求 在在覆盖 一个logfile 之前 ”changes recorded in it have
been checkpointed (written) to disk by database writer (DBWn).“

来看一个 log switch checkpoint:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SQL> archive log list;
Database log mode              Archive Mode


SQL> alter system set log_checkpoints_to_alert=TRUE;

System altered.


SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         17   52428800          2 NO  CURRENT               15162545 09-MAR-12
         2          1         16   52428800          2 YES INACTIVE              15162538 09-MAR-12
         3          1         15   52428800          2 YES INACTIVE              15162531 09-MAR-12


CURRENT LOGFILE 是 GROUP #1

do some dml!!


SQL> alter system switch logfile;

System altered.

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         17   52428800          2 YES ACTIVE                15162545 09-MAR-12
         2          1         16   52428800          2 YES INACTIVE              15162538 09-MAR-12
         3          1         18   52428800          2 NO  CURRENT               15162655 09-MAR-12


切换日志后 ， GROUP #1 的redo log变为active 状态 ， 同时也开始了一个 logfile switch checkpoint

alert.log 中会出现

Beginning log switch checkpoint up to RBA [0x12.2.10], SCN: 15162655  ==》注意它只是一个开始　，并没有完成

可以看到checkpoint的终点是  SCN 15162655 即 GROUP #1的end ，RBA [0x12.2.10] 即 sequence 18

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.


在做2次 logfile switch 会导致 需要 再次切换到 GROUP #1 ，并覆盖GROUP #1 ，这要求完成 “Beginning log switch checkpoint up to RBA [0x12.2.10], SCN: 15162655 ”

alert 中可以找到：

Thread 1 cannot allocate new log, sequence 20
Checkpoint not complete
Completed checkpoint up to RBA [0x12.2.10], SCN: 15162655


SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         20   52428800          2 NO  CURRENT               15162703 09-MAR-12
         2          1         19   52428800          2 YES INACTIVE              15162700 09-MAR-12
         3          1         18   52428800          2 YES INACTIVE              15162655 09-MAR-12

GROUP #1 现在就是sequence 20 ，为什么“cannot allocate new log, sequence 20” ，因为 Checkpoint not complete 检查点未完成， 直到 “Completed checkpoint up to RBA [0x12.2.10], SCN: 15162655“ logfile switch checkpoint 完成了， 才允许allocate new log sequence 20

lghwf

我理解是这样的，
  REDO LOG 文件在被重用时，系统要保证被这个REDO 文件保护的缓冲区里被修改的数据已经被写到磁盘里去了。
11G 的概念文档里关于redo log 有这一段：
Filled online redo log files are available for reuse depending on the archiving mode:
■ If archiving is disabled, which means that the database is in NOARCHIVELOG mode,
then a filled online redo log file is available after the changes recorded in it have
been checkpointed (written) to disk by database writer (DBWn).
■ If archiving is enabled, which means that the database is in ARCHIVELOG mode,
then a filled online redo log file is available to log writer after the changes have been written to the data files and the file has been archived.
In some circumstances, log writer may be prevented from reusing an existing online
redo log file. For example, an online redo log file may be active (required for instance
recovery) rather than inactive (not required for instance recovery). Also, an online
redo log file may be in the process of being cleared.

Maclean Liu(刘相兵

问题描述地不是很清楚，  把你的看的文档 贴全一点 ， 指出出处 ， 不要断章取义！