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

lipanzjzs

越看越觉得学得要更多。感谢 。

grassbell

如果大家感兴趣，可以看原文。

grassbell

对于4/5 两种重建控制文件的情况的问题？

针对数据文件的Checkpoint scn都有记载。这些信息应该是从系统表空间中读取后加载到控制文件中的吧？而不是从数据文件的头信息中读取的。
我曾作了一个试验，就是用一个用备份的users02.dbf 代替了现有的文件，然后重建控制文件。这时控制文件中users02.dbf 的Checkpoint scn和其他文件仍然是一样的。(备份后，执行了checkpoint的)

grassbell

沉吧，沉的让我找不到你吧！
辛苦了一天的贴子，过一会就找不到了。

CrazyCpy

最初由 grassbell 发布
[B]沉吧，沉的让我找不到你吧！
辛苦了一天的贴子，过一会就找不到了。 [/B]

不能沉，已经保存，慢慢看.............................

j2wk

最初由 grassbell 发布
[B]对于4/5 两种重建控制文件的情况的问题？

针对数据文件的Checkpoint scn都有记载。这些信息应该是从系统表空间中读取后加载到控制文件中的吧？而不是从数据文件的头信息中读取的。
我曾作了一个试验，就是用一个用备份的users02.dbf 代替了现有的文件，然后重建控制文件。这时控制文件中users02.dbf 的Checkpoint scn和其他文件仍然是一样的。(备份后，执行了checkpoint的) [/B]

这个应该好理解：正常情况下所有数据文件和控制文件，联机日志应处在同一SCN点上，重建控制文件时，ORACLE只会检测你的数据文件是不是有效文件，然后在控制文件中确定当前的SCN点，同时各数据文件的SCN点也是相同的。在打开数据库时（实际上MOUNT时就已经检测到了），ORACLE检测到这个USERS02.DBF文件的SCN与控制文件中的SCN不一致，则会提醒要求RECOVER（V$RECOVER_FILE）。并根据控制文件中的记录的归档日志信息确定这个RECOVER过程将要用到哪几个归档文件（V$RECOVERY_LOG ）。
   对于这个问题，还是存在一个疑问，就是新建控制文件时，执行RECOVER 时ORACLE会提醒归档文件的名称，这个归档文件名是怎么得来的，ORACLE怎么知道要这个文件？？？因为这时新建的控制文件中的归档信息没有了！！！BITI的观点是ORACLE会从数据文件头中读过来？！！呵呵就算数据文件头中记录了一个归档序列号，但通常恢复时需要的也不止一个归档文件啊，它怎么知道下一个归档文件名？？？？
   头大，想不明白！有什么好的解释吗。

biti_rainy

最初由 j2wk 发布
[B]

BITI的观点是ORACLE会从数据文件头中读过来？！！呵呵就算数据文件头中记录了一个归档序列号，但通常恢复时需要的也不止一个归档文件啊，它怎么知道下一个归档文件名？？？？
   头大，想不明白！有什么好的解释吗。 [/B]

这个……要为了维护这个观点的话很简单呀   

当你应用完一个归档后，数据文件头的记录，或者说 记录已经应用的日志的序列号，或者说，记录上一个检查点时候的日志的序号，已经发生了变化啊，为什么还要站在原来的 地方 看待变化的事物呢  ？

biti_rainy

其实在我第一次回答你这个问题的时候，也就是我可能说出错误的东西的时候（我说可能根据数据文件头和归档去做比较），我早已经把 后面陈述的观点想过了，并且做过简单的实验，可惜没有证据严格表明后面的观点是正确的，当时上班正忙没有时间去过多的验证什么。于是抛出了前面的一个可能的观点。

后来你用事实证明这个观点站不住脚，我才抛出了后面这个观点，虽然我没有证明这个观点是对的，但也没有证明是错误的。 如果是错误的，那我觉得，就玄乎了，呵呵

j2wk

最初由 biti_rainy 发布
[B]其实在我第一次回答你这个问题的时候，也就是我可能说出错误的东西的时候（我说可能根据数据文件头和归档去做比较），我早已经把 后面陈述的观点想过了，并且做过简单的实验，可惜没有证据严格表明后面的观点是正确的，当时上班正忙没有时间去过多的验证什么。于是抛出了前面的一个可能的观点。

后来你用事实证明这个观点站不住脚，我才抛出了后面这个观点，虽然我没有证明这个观点是对的，但也没有证明是错误的。 如果是错误的，那我觉得，就玄乎了，呵呵 [/B]

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

卷心菜

再顶，为grassbell的钻研精神