数据库open时检查点执行的过程

exitgogo

最初由 eygle 发布
[B]

数据库在启动过程中所做的检查不止以上两类，实际上还有很多需要检查。

对于历史文件，数据文件头会包含Checkpointed scn，如果这个SCN小于控制文件中记录的on disk scn，那么这个文件显然需要恢复。 [/B]

看过大师写的那本书，很是不错，浅入深出，由点到线，由线到面，然后豁然开朗。

好像书上对oracle open过程只是说了以上的2个步骤呀！

对与oracle提示数据文件需要恢复的检测，是首先比较数据文件Checkpointed scn与控制文件中记录的Checkpointed scn，然后在比较数据文件Checkpointed scn与控制文件中记录的on disk scn是否一致，是这样吗？
请大师指点！

exitgogo

最初由 eygle 发布
[B]

你可能搞错了！
在dump数据文件头的时候，信息包括2部分，一部分来自控制文件，一部分来自文件头，如果你只看控制文件部分就一直没变化了。

请看以下例子：
这部分来自控制文件：
[php]
DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:50 scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Stop scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
[/php]

这部分才是来自文件头：
注意这里的:Checkpointed at scn:  0x0000.002ac55d 08/10/2006 10:44:29

[php]
FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=960=0x3c0, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 06/26/2006 13:44:28
status:0x0 root dba:0x00000000 chkpt cnt: 46 ctl cnt:45
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac55d 08/10/2006 10:44:29
thread:1 rba0x35.11d6.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Backup Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00
DUMP OF TEMP FILES: 0 files in database
DUMP OF CONTROL FILES, Seq # 967 = 0x3c7
FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=967=0x3c7, File size=228=0xe4
        File Number=0, Blksiz=8192, File Type=1 CONTROL
.[/php] [/B]

多谢大师指点，现在豁然开朗，明白了很多，大师就是大师！
呵呵！

leetaedong

最初由 eygle 发布
[B]
chkpt cnt也是不同的，文件就是来自于不同的版本了:
chkpt cnt: 46 ctl cnt:45 [/B]

eygle，这个好像是Backup taken 条目下的chkpt cnt，跟这个关系不大。你可以看看undo file的这部分，一样的相差 1(虽然它们来自相同的版本)，而且它还是ctl cn要小。

eygle

最初由 leetaedong 发布
[B]

eygle，这个好像是Backup taken 条目下的chkpt cnt，跟这个关系不大。你可以看看undo file的这部分，一样的相差 1(虽然它们来自相同的版本)。 [/B]

我不是说46和45差1

而是你向上看来自控制文件部分：
Checkpoint cnt:50 scn: 0x0000.002ac5aa 08/10/2006 10:46:03

和来自数据文件头部分:
status:0x0 root dba:0x00000000 chkpt cnt: 46 ctl cnt:45
....
Checkpointed at scn:  0x0000.002ac55d 08/10/2006 10:44:29

你仔细看看，或者测试一下！

leetaedong

被ctl cnt 这个东西麻痹了，我以前你说的这个ctl cnt
是controlfile里记录的这个数据文件的checkpoint count。
实际上不是的。

eygle

最初由 exitgogo 发布
[B]


看过大师写的那本书，很是不错，浅入深出，由点到线，由线到面，然后豁然开朗。

好像书上对oracle open过程只是说了以上的2个步骤呀！

对与oracle提示数据文件需要恢复的检测，是首先比较数据文件Checkpointed scn与控制文件中记录的Checkpointed scn，然后在比较数据文件Checkpointed scn与控制文件中记录的on disk scn是否一致，是这样吗？
请大师指点！ [/B]

数据库启动过程要做的校验有很多，为了不把书的内容搞得太复杂，我就介绍了最重要和大家最熟知的两种，更主要的是介绍方法，这样大家就都可以动手实验、测试并且验证我所说的内容。

以上这个问题，实际上通过checkpoint cnt/scn就可以判断了。

on disk scn在恢复时被用到

exitgogo

最初由 leetaedong 发布
[B]
被ctl cnt 这个东西麻痹了，我以前你说的这个ctl cnt
是controlfile里记录的这个数据文件的checkpoint count。
实际上不是的。 [/B]

那么这个ctl cnt该怎么解释呀！

eygle

最初由 cicro 发布
[B]
alter session set events 'immediate trace name file_hdrs level 10';此条语句获取了数据文件头信息，他是从哪里获取的数据文件信息呀，不明白了，请大师们指点一二！ [/B]

关于file_hdrs 的dump哪些信息来自控制文件，哪些信息来自数据文件，通过一个简单的测试就可以明确。

我们可以在mount状态下删除文件，对比正常情况下，就可以确定。

来看一下测试:
如果文件丢失，file_hdrs 只能显示来自控制文件的信息：
[php]
DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:50 scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Stop scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/opt/oracle/oradata/eygle/eygle01.dbf'
*** Error 1157 in open/read file # 4 ***
.
[/php]
到ORA-01157错误之前的信息来自控制文件。

再看文件存在情况下：
[php]
DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:50 scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Stop scn: 0x0000.002ac5aa 08/10/2006 10:46:03
Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
' aux_file is NOT DEFINED '
FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=960=0x3c0, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 06/26/2006 13:44:28
status:0x0 root dba:0x00000000 chkpt cnt: 46 ctl cnt:45
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac55d 08/10/2006 10:44:29
thread:1 rba0x35.11d6.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Backup Checkpointed at scn:  0x0000.00000000
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00
.[/php]

从 'aux_file is NOT DEFINED' 之后的信息就是来自数据文件头。

Talmud

mount的时候应该并没有读取数据文件（头），但是在任何需要的时候可以随时读取数据文件头的信息。
比如查询v$datafile_header,dump 数据文件头，下恢复文件命令等等。

Talmud

最初由 eygle 发布
[B]

数据库启动过程要做的校验有很多，为了不把书的内容搞得太复杂，我就介绍了最重要和大家最熟知的两种，更主要的是介绍方法，这样大家就都可以动手实验、测试并且验证我所说的内容。

以上这个问题，实际上通过checkpoint cnt/scn就可以判断了。

on disk scn在恢复时被用到 [/B]

on disk scn从字面上看应该是指DBWN写入磁盘的scn，应该是用于instance恢复时开始恢复的scn吧？

对从备份文件恢复应该不会有用。理解对否？