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

cicro

UP！

Talmud

说说我的理解：
mount时当然会去读数据文件头，所以你在mount下dump出来的信息是实际的数据文件头信息。而你的控制文件中该文件的信息也是在读取了数据文件头后的新的信息。


两个scnCheckpoint cnt:126 scn: 0x0800.01952813 08/09/2006 17:38:53
Stop scn: 0xffff.ffffffff 08/09/2006 17:38:07
其中Stop scn在数据库运行时是一个很大的值，当数据库正常关闭时会修改Stop scn，使其和上面checkpoint scn一致。所以在启动时如果发现这两个scn不一致，是需要恢复的。

在你的情况下，只是说控制文件中/opt/oracle/oradata/cicro/cicrodb.dbf文件的scn信息和数据文件头中该文件的scn信息一致（当然是一致的，前者是从后者读来的）。但是控制文件中还记录着最后checkpoint的scn，要大于该数据文件的scn。而且其他文件的scn和这个文件的scn也不一致，当然需要恢复了。

我的解释只供参考。

eygle

最初由 cicro 发布
[B]
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 11 needs media recovery
ORA-01110: data file 11: '/opt/oracle/oradata/cicro/cicrodb.dbf'

却报/opt/oracle/oradata/cicro/cicrodb.dbf需要恢复，这个是怎么回事，请大师指点！

谢谢eygle！ [/B]

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

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

Talmud

sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.6.0 - Production on Sat Jul 22 18:39:19 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning option
JServer Release 9.2.0.6.0 - Production

SQL> alter session set events 'immediate trace name CONTROLF level 10' ;

Session altered.

SQL> @gettracefile

TRACE_FILE_NAME
------------------------------------------------------------------------------------------------------------------------
d:\oracle\admin\ora920\udump\ora920_ora_3848.trc



*** 2006-07-26 11:32:20.149
DUMP OF CONTROL FILES, Seq # 1661 = 0x67d
FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=2602367092=0x9b1cf874, Db Name='ORA920'            --------------数据库dbid和数据库名称
        Activation ID=0=0x0
        Control Seq=1661=0x67d, File size=246=0xf6                    ----------这个seq是指？
        File Number=0, Blksiz=8192, File Type=1 CONTROL




***************************************************************************
DATABASE ENTRY
***************************************************************************
(blkno = 0x1, size = 192, max = 1, in-use = 1, last-recid= 0)
DF Version: creation=0x9200000 compatible=0x8000000, Date  07/12/2006 16:42:28
DB Name "ORA920"
Database flags = 0x00404001
Controlfile Creation Timestamp  07/12/2006 16:42:29
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.0031e017 Resetlogs Timestamp  07/26/2006 10:59:33
Prior resetlogs scn: 0x0000.0002e872 Prior resetlogs Timestamp  07/12/2006 16:42:29
Redo Version: creation=0x9200000 compatable=0x9200000
#Data files = 11, #Online files = 11
Database checkpoint: Thread=1 scn: 0x0000.0031e018
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Max log members = 5, Max data members = 1
Arch list: Head=3, Tail=3, Force scn: 0x0000.00000000scn: 0x0000.003013cf
Controlfile Checkpointed at scn:  0x0000.0031e03c 07/26/2006 10:59:41
thread:0 rba0x0.0.0)
---------------正常online的时候rba为0，thread 0表示没有redo要应用来恢复数据库。
---------------在数据库不一致时，就会有相关的值从数据文件头读出。
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000




***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(blkno = 0x4, size = 104, max = 1, in-use = 1, last-recid= 0)
THREAD #1 - status:0x2 flags:0x0 dirty:65
low cache rba0x1.28c.0) on disk rba0x1.f20.0)
on disk scn: 0x0000.0031f3a8 07/26/2006 11:32:07
---------------竟然大于"DATABASE ENTRY"中的controlfiel Checkpointed at scn。这个怎么解释？相差超过半个小时！

resetlogs scn: 0x0000.0031e017 07/26/2006 10:59:33
heartbeat: 596786839 mount id: 2603565311
MTTR statistics status: 3
Init time: Avg: 17149513, Times measured: 3
File open time: Avg: 126237, Times measured: 36
Log block read time: Avg: 46, Times measured: 36394
Data block handling time: Avg: 4978, Times measured: 437          <------这几项计数怎么看呢？




***************************************************************************
EXTENDED DATABASE ENTRY
***************************************************************************
(blkno = 0x7a, size = 276, max = 1, in-use = 1, last-recid= 0)
Control AutoBackup date(dd/mm/yyyy)=12/ 7/2006
Next AutoBackup sequence= 0



***************************************************************************
REDO THREAD RECORDS
***************************************************************************
(blkno = 0x4, size = 104, max = 1, in-use = 1, last-recid= 0)
THREAD #1 - status:0xf thread links forward:0 back:0
#logs:3 first:1 last:3 current:3 last used seq#:0x1
enabled at scn: 0x0000.0031e017 07/26/2006 10:59:33
disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
opened at 07/26/2006 10:59:39 by instance ora920
Checkpointed at scn:  0x0000.0031e018 07/26/2006 10:59:39
thread:1 rba0x1.2.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
log history: 0




***************************************************************************
LOG FILE RECORDS
***************************************************************************
(blkno = 0x5, size = 72, max = 50, in-use = 3, last-recid= 6)
LOG FILE #1:
  (name #3) D:\ORACLE\ORADATA\ORA920\REDO01.LOG
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x32000 seq: 0x00000000 hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.00000000 01/01/1988 00:00:00
Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #2:
  (name #2) D:\ORACLE\ORADATA\ORA920\REDO02.LOG
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x32000 seq: 0x00000000 hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.00000000 01/01/1988 00:00:00
Next scn: 0x0000.00000000 01/01/1988 00:00:00
LOG FILE #3:
  (name #1) D:\ORACLE\ORADATA\ORA920\REDO03.LOG
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x32000 seq: 0x00000001 hws: 0x3 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
--------------------------- siz: 0x32000是指块尺寸，而块的大小是bsz: 512 ，总的大小是100M。

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00000000
Low scn: 0x0000.0031e017 07/26/2006 10:59:33
Next scn: 0xffff.ffffffff 07/26/2006 10:59:33
------------------------一个logfile的文件名，thread,循环使用的前后日志，因为是当前日志，当然只能把Next scn置为最大值。





***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 11, last-recid= 641)
DATA FILE #1:
  (name #8) D:\ORACLE\ORADATA\ORA920\SYSTEM01.DBF
creation size=0 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 0, index=6 krfil=1 prev_file=0
------------记录了数据文件号、文件名称、块尺寸、状态、表空间、及其他信息。

unrecoverable scn: 0x0000.00000000 07/18/2006 13:14:42
Checkpoint cnt:319 scn: 0x0000.0031e018 07/26/2006 10:59:39
Stop scn: 0xffff.ffffffff 07/26/2006 10:59:33
------------online数据文件，其stop scn为无穷大的值。

Creation Checkpointed at scn:  0x0000.0000000b 05/12/2002 16:17:58
-----------创建的时间和scn，这个对于恢复丢失后的文件，可以使用alter database create datafile '' as '' reuse；来恢复，保证知道这样创建的文件需要哪些日志文件。
thread:0 rba0x0.0.0)
enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Offline scn: 0x0000.0031e016 prev_range: 0
Online Checkpointed at scn:  0x0000.0031e017 07/26/2006 10:59:33
thread:1 rba0x1.2.0)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
.....

以前也研究过，但看的时候也不是理解的很清晰。
希望大家多讨论释疑。

Talmud

Controlfile Checkpointed at scn: 0x0000.0031e03c 07/26/2006 10:59:41

on disk scn: 0x0000.0031f3a8 07/26/2006 11:32:07

谁能够解释解释一下这两个scn的不同？

exitgogo

最初由 Talmud 发布
[B]说说我的理解：
mount时当然会去读数据文件头，所以你在mount下dump出来的信息是实际的数据文件头信息。而你的控制文件中该文件的信息也是在读取了数据文件头后的新的信息。


两个scnCheckpoint cnt:126 scn: 0x0800.01952813 08/09/2006 17:38:53
Stop scn: 0xffff.ffffffff 08/09/2006 17:38:07
其中Stop scn在数据库运行时是一个很大的值，当数据库正常关闭时会修改Stop scn，使其和上面checkpoint scn一致。所以在启动时如果发现这两个scn不一致，是需要恢复的。

在你的情况下，只是说控制文件中/opt/oracle/oradata/cicro/cicrodb.dbf文件的scn信息和数据文件头中该文件的scn信息一致（当然是一致的，前者是从后者读来的）。但是控制文件中还记录着最后checkpoint的scn，要大于该数据文件的scn。而且其他文件的scn和这个文件的scn也不一致，当然需要恢复了。

我的解释只供参考。 [/B]

我做了一下测试，在这种情况下，其它文件的scn也和/opt/oracle/oradata/cicro/cicrodb.dbf的scn是一样的，checkpoint cnt是检查数据文件的版本是否一致，checkpoint scn是检测用于恢复的，

也就是说此时所有数据文件的scn是一致的，

同时又做了一个测试，删除刚才的那个cicrodb。dbf文件，mount后，同样cicrodb.dbf的checkpoint scn与其它scn仍就一样，

所以结论是数据库在mount的时候是不去读取数据文件的，但是dump出来的数据文件头信息是从哪里来的呢，

疑惑中！

leetaedong

在你的情况下，只是说控制文件中/opt/oracle/oradata/cicro/cicrodb.dbf文件的scn信息和数据文件头中该文件的scn信息一致（当然是一致的，前者是从后者读来的）。

我觉得这句话说反了。

到底在mount状态，dump出来的信息是来自数据文件头还是
控制文件？

按说应该是数据文件头中的，但是好像test结果好像与这个相反。

exitgogo

最初由 leetaedong 发布
[B]

我觉得这句话说反了。

到底在mount状态，dump出来的信息是来自数据文件头还是
控制文件？

按说应该是数据文件头中的，但是好像test结果好像与这个相反。 [/B]

我决的dump出来的应该不是来自数据文件，应该是来自控制文件的信息，因为此时数据文件还没有被读取，数据文件只有在open时刻才被数据库读取。

那么dump出来的数据文件头信息，也应该是来自控制文件了！

不知对否，请大师讲解一下吧！

eygle

最初由 exitgogo 发布
[B]


我做了一下测试，在这种情况下，其它文件的scn也和/opt/oracle/oradata/cicro/cicrodb.dbf的scn是一样的，checkpoint cnt是检查数据文件的版本是否一致，checkpoint scn是检测用于恢复的，

也就是说此时所有数据文件的scn是一致的，

同时又做了一个测试，删除刚才的那个cicrodb。dbf文件，mount后，同样cicrodb.dbf的checkpoint scn与其它scn仍就一样，

所以结论是数据库在mount的时候是不去读取数据文件的，但是dump出来的数据文件头信息是从哪里来的呢，

疑惑中！ [/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]

eygle

在以上的例子中，可以看到文件头记录的checkpoint scn和控制文件中记录的是不同的。

这就肯定需要恢复了。

chkpt cnt也是不同的，文件就是来自于不同的版本了:
chkpt cnt: 46 ctl cnt:45