对多种情况下控制文件的理解与疑问，请指正。

biti_rainy

最初由 j2wk 发布
[B]

BITI兄，没有贬你观点的意思，只是觉得一直找不到一个合适的解说头痛不已。唉，这个问题还是搁在我心里，不爽！！ [/B]

如果检查点对应的  日志序号信息 在数据文件头，并没有不合理啊

假如现在是  x, 则 需要归档日志序号假设是 x+1
当你应用了归档x+1 的时候，数据文件有的信息也变为 x+1 了，自然就提示  需要的归档日志序号是 x+2 了

怎么会存在你所说的  数据文件头只保存一个不保存所有 所以无法解释  需要归档日志序号的变化的问题呢 ？

j2wk

最初由 biti_rainy 发布
[B]

如果检查点对应的  日志序号信息 在数据文件头，并没有不合理啊

假如现在是  x, 则 需要归档日志序号假设是 x+1
当你应用了归档x+1 的时候，数据文件有的信息也变为 x+1 了，自然就提示  需要的归档日志序号是 x+2 了

怎么会存在你所说的  数据文件头只保存一个不保存所有 所以无法解释  需要归档日志序号的变化的问题呢 ？ [/B]

呵呵我明白你的意思，你是说它会去累加这个序列号是吧，也不是全不赞同，只是没有证据来证明。

j2wk

不要沉啊，这是个好贴啊。

biti_rainy

最初由 j2wk 发布
[B]

呵呵我明白你的意思，你是说它会去累加这个序列号是吧，也不是全不赞同，只是没有证据来证明。 [/B]

其实非要说证据么？  也是很简单的！

只使用数据文件，不要控制文件和日志文件,所有归档日志转移到非 设置目录
创建控制文件(resetlogs方式)
然后尝试 recover , 提示的时候，输入归档文件（新目录下）
然后关闭数据库，再创建控制文件
再recover，提示正常增加了序列1

这样的实验，虽然没有直接找到 数据文件头信息的证明
但是，依然间接证明了 信息来自数据文件头，因为除了这里没有其他来源了

我在dump  controlfile  or  datafile  header 的时候,trace file 没有输出 这个信息，所以 没有直接证明，但是从间接的角度来说，依然可以说明这个问题

grassbell

是的，数据文件头信息中记载了日志序号.

我在metalink上找到这么一句话：
Information in the datafile header
==================================  
- Log sequence number of next log file that could be applied.
- Whether online backup in progress.

j2wk

最初由 grassbell 发布
[B]是的，数据文件头信息中记载了日志序号.

我在metalink上找到这么一句话：
Information in the datafile header
==================================  
- Log sequence number of next log file that could be applied.
- Whether online backup in progress. [/B]

哦，可否告诉我此文的链接？我在METALINK上搜了下，没找到。
另外，METALINK上文档我从来就保存不下来，有什么法子吗？
感谢 GRASSBELL AND BITI   ：）

grassbell

最初由 j2wk 发布
[B]

哦，可否告诉我此文的链接？我在METALINK上搜了下，没找到。
另外，METALINK上文档我从来就保存不下来，有什么法子吗？
感谢 GRASSBELL AND BITI   ：） [/B]

http://metalink.oracle.com/metal ... OT&p_id=16530.1

好像我的问题一个也没有得到回答哦？！

j2wk

补充一下：重建控制文件时，控制文件的SCN号是从当前联机日志文件中获得的。（METALINK ）

j2wk

最初由 grassbell 发布
[B]

http://metalink.oracle.com/metal ... OT&p_id=16530.1

好像我的问题一个也没有得到回答哦？！ [/B]

呵呵，谢过！你有法子保存METALINK上的文档吗？

biti_rainy

sys@OCN>select max(NEXT_CHANGE#) from v$archived_log;    --------  已经归档的最大 scn

MAX(NEXT_CHANGE#)
-----------------
       1474525306
sys@OCN>select CHECKPOINT_CHANGE#  from v$database;            --------  当前数据库的检查点scn

CHECKPOINT_CHANGE#
------------------
        1474347373
sys@OCN>select   CONTROLFILE_CHANGE#  from v$database;

CONTROLFILE_CHANGE#
-------------------
         1474698819
sys@OCN>select checkpoint_change# from v$datafile where rownum = 1;    -------  数据文件中的检查点scn

CHECKPOINT_CHANGE#
------------------
        1474347373
sys@OCN>desc dbms_flashback     
PROCEDURE DISABLE
PROCEDURE ENABLE_AT_SYSTEM_CHANGE_NUMBER
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
QUERY_SCN                      NUMBER                  IN
PROCEDURE ENABLE_AT_TIME
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
QUERY_TIME                     TIMESTAMP               IN
FUNCTION GET_SYSTEM_CHANGE_NUMBER RETURNS NUMBER

sys@OCN>select  dbms_flashback.GET_SYSTEM_CHANGE_NUMBER  from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
              1474709195
sys@OCN>select   CONTROLFILE_CHANGE#  from v$database;

CONTROLFILE_CHANGE#
-------------------
         1474710528
sys@OCN>select  dbms_flashback.GET_SYSTEM_CHANGE_NUMBER  from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
              1474711660
sys@OCN>



CONTROLFILE_CHANGE#  几乎总是接近于当前系统的最新的 SCN ，控制文件每3秒就被检查点进程更新了一次的


我们可以看见，日志文件已经归档了，结果 检查点 scn 还小于  已经归档文件的 scn ，实际上这是 增量检查点的机制所导致的。也就是说系统累计了大量 dirty  buffer 没有写完，发展下去，所日志切换一圈追上了 检查点所处的 日志文件，则会系统警告：  checkpoint not  complete  ,这个时候一般建议增加日志组和增大日志文件大小，或者想办法提高 dbwr写入速度  




on disk scn: 0x0000.0040005b    --------  写入日志文件的的最大 SCN ，可以理解为 日志文件中内容的最大SCN