为何不重建控制文件就不需要介质恢复了?肯定重建的控制文件中丢失了一些信息
于是进行了下研究
/
/
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/