数据库非正常关闭后重建控制文件，OPEN时为何需要执行介质恢复？

今天测试点东西，发现数据库非正常关闭后重建控制文件，OPEN时需要进行介质恢复

 

为何不重建控制文件就不需要介质恢复了？肯定重建的控制文件中丢失了一些信息

于是进行了下研究

 

alter system switch logfile;

/

/

shutdown abort;

startup mount;

ALTER SESSION SET EVENTS 'immediate trace name controlf level 15';

shutdown abort;

startup nomount;

CREATE CONTROLFILE REUSE DATABASE "O11203"  NORESETLOGS FORCE LOGGING ARCHIVELOG

    MAXLOGFILES 16

    MAXLOGMEMBERS 3

    MAXDATAFILES 100

    MAXINSTANCES 8

    MAXLOGHISTORY 292

LOGFILE

  GROUP 1 '/u01/app/oracle/oradata/o11203/redo01.log'  SIZE 50M BLOCKSIZE 512,

  GROUP 2 '/u01/app/oracle/oradata/o11203/redo02.log'  SIZE 50M BLOCKSIZE 512,

  GROUP 3 '/u01/app/oracle/oradata/o11203/redo03.log'  SIZE 50M BLOCKSIZE 512

-- STANDBY LOGFILE

DATAFILE

  '/u01/app/oracle/oradata/o11203/system01.dbf',

  '/u01/app/oracle/oradata/o11203/sysaux01.dbf',

  '/u01/app/oracle/oradata/o11203/undotbs01.dbf',

  '/u01/app/oracle/oradata/o11203/users01.dbf',

  '/u01/app/oracle/oradata/o11203/streams_tbs.dbf'

CHARACTER SET ZHS16GBK

;

ALTER SESSION SET EVENTS 'immediate trace name controlf level 15';

 

对比重建前和重建后控制文件的DUMP，发现区别

1.   DB CHECKPOINT SCN发生了变化

 

重建前：

Database checkpoint: Thread=1 scn: 0x0000.003d786f

重建后：

Database checkpoint: Thread=1 scn: 0x0000.003d7d6a

2.   low cache rba & on disk rba 被清空

重建前

THREAD #1 - status:0x2 flags:0x0 dirty:10105

low cache rba:(0x16d.840a.0) on disk rba:(0x16f.3358.0)

on disk scn: 0x0000.003d7f92 06/24/2013 15:14:55

resetlogs scn: 0x0000.00000001 05/10/2013 11:33:26

重建后

THREAD #1 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

 

3.   数据文件/CURR日志文件的CHECKPOINT SCN有变化

重建前

Checkpoint cnt:471 scn: 0x0000.003d786f 06/24/2013 15:13:29

重建后

Checkpoint cnt:471 scn: 0x0000.003d7d6a 01/01/1988 00:00:00

 

可以看到，所有的CHECKPOINT SCN都变大了,这个3d7d6a从何而来

从0x0000.003d786f -> 0x0000.003d7d6a

 

dump filehdr来看，文件头的SCN确实为0x0000.003d786f

Tablespace #0 - SYSTEM  rel_fn:1

Creation   at   scn: 0x0000.00000011 05/10/2013 11:34:09

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

 reset logs count:0x3094b806 scn: 0x0000.00000001

 prev reset logs count:0x0 scn: 0x0000.00000000

 recovered at 06/24/2013 15:12:47

 status:0x2004 root dba:0x00400208 chkpt cnt: 471 ctl cnt:470

begin-hot-backup file size: 0

Checkpointed at scn:  0x0000.003d786f 06/24/2013 15:13:29

 thread:1 rba:(0x16d.2.10)

 

接着dump redohdr，发现0x003d786f其实为redo log 的Low scn

FILE HEADER:

        Compatibility Vsn = 186646528=0xb200000

        Db ID=3974789702=0xecea7a46, Db Name='O11203'

        Activation ID=3974791238=0xecea8046

        Control Seq=7328=0x1ca0, File size=102400=0x19000

        File Number=1, Blksiz=512, File Type=2 LOG

 Format ID is 2

 redo log key is 0d669cf25eddaf3e22578bbd327d4d

 redo log key flag is 5

 descrip:"Thread 0001, Seq# 0000000367, SCN 0x0000003d7d6a-0xffffffffffff"

 thread: 1 nab: 0xffffffff seq: 0x0000016f hws: 0x1 eot: 1 dis: 0

 reset logs count: 0x3094b806 scn: 0x0000.00000001

 Low scn: 0x0000.003d7d6a 06/24/2013 15:14:34

 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

 Enabled scn: 0x0000.00000001 05/10/2013 11:33:34

 Thread closed scn: 0x0000.003d7d6a 06/24/2013 15:14:34

 Disk cksum: 0xaaea Calc cksum: 0xaaea

 Terminal Recovery Stop scn: 0x0000.00000000

 Terminal Recovery Stamp  01/01/1988 00:00:00

 Most recent redo scn: 0x0000.00000000

 Largest LWN: 0 blocks

 Miscellaneous flags: 0x800000

 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

 Zero blocks: 0

 Enabled redo threads: 1

 

也就是说，重建控制文件时，会取curr日志组的low scn作为db checkpoint scn，并且所有控制文件记录中的数据文件的checkpoint scn也被赋予该scn

 

然后，控制文件中的数据文件ckpt scn和数据文件头的ckpt scn不一致，那么必然需要介质恢复

 

那重建控制文件是否不需要数据文件真实存在了？不行，需要。重建的时候要验证。并且文件头的数据要正常。

 

还有个问题，如果是resetlogs，那情况会如何？

1.   DB CKPT SCN会被清空。

2.   由于REDO LOG需要被清空，所以控制文件中除去文件名外没有其他redo信息

3.   数据文件部分的SCN从数据文件头读取，就是数据文件的CHECKPOINT SCN

4.   这时恢复就是一个简单的数据文件恢复，需要手工指定日志位置

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8242091/viewspace-764676/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-764676/