資料庫非正常關閉後重建控制檔案，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/，如需轉載，請註明出處，否則將追究法律責任。