感兴趣的还是记得去看原帖子，笔记有删减，原作者微信公众号：
对于控制文件，其中究竟包含了哪些内容，实际上我们可以通过查询V$CONTROLFILE_RECORD_SECTION 来进行确认（不同版本查询结果会有差异）.
这里我以Oracle 11.2.0.4为例：
set linesize 1000 pagesize 100
select * from V$CONTROLFILE_RECORD_SECTION ;
TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID CON_ID
------------------------------ ----------- ------------- ------------ ----------- ---------- ---------- ----------
TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
------------------------------ ----------- ------------- ------------ ----------- ---------- ----------
DATABASE 316 1 1 0 0 0
CKPT PROGRESS 8180 11 0 0 0 0
REDO THREAD 256 8 1 0 0 0
REDO LOG 72 16 3 0 0 3
DATAFILE 520 100 5 0 0 26
FILENAME 524 2298 9 0 0 0
TABLESPACE 68 100 6 0 0 2
TEMPORARY FILENAME 56 100 1 0 0 10
RMAN CONFIGURATION 1108 50 0 0 0 0
LOG HISTORY 56 292 25 1 25 25
OFFLINE RANGE 200 163 3 1 3 3
ARCHIVED LOG 584 28 2 1 2 2
BACKUP SET 40 409 0 0 0 0
BACKUP PIECE 736 200 0 0 0 0
BACKUP DATAFILE 200 245 0 0 0 0
BACKUP REDOLOG 76 215 0 0 0 0
DATAFILE COPY 736 200 0 0 0 0
BACKUP CORRUPTION 44 371 0 0 0 0
COPY CORRUPTION 40 409 0 0 0 0
DELETED OBJECT 20 818 0 0 0 0
PROXY COPY 928 246 0 0 0 0
BACKUP SPFILE 124 131 0 0 0 0
DATABASE INCARNATION 56 292 2 1 2 2
FLASHBACK LOG 84 2048 0 0 0 0
RECOVERY DESTINATION 180 1 0 0 0 0
INSTANCE SPACE RESERVATION 28 1055 1 0 0 0
REMOVABLE RECOVERY FILES 32 1000 0 0 0 0
RMAN STATUS 116 141 0 0 0 0
THREAD INSTANCE NAME MAPPING 80 8 8 0 0 0
MTTR 100 8 1 0 0 0
DATAFILE HISTORY 568 57 0 0 0 0
STANDBY DATABASE MATRIX 400 31 31 0 0 0
GUARANTEED RESTORE POINT 212 2048 0 0 0 0
RESTORE POINT 212 2083 0 0 0 0
DATABASE BLOCK CORRUPTION 80 8384 0 0 0 0
ACM OPERATION 104 64 6 0 0 0
FOREIGN ARCHIVED LOG 604 1002 0 0 0 0
37 rows selected.
我们可以看到在11g中，实际上控制文件中包含了37类信息(19c是42条记录，23c是43条记录），当然其中只有少部分信息才是我们所关注的重点，大部分信息对我们做数据恢复而言，没什么实际用处。
关键信息都在控制文件前面几个block中，如下是Oracle 11g的dump:
oradebug setmypid
ALTER SESSION SET EVENTS 'immediate trace name controlf level 1';
oradebug close_trace
oradebug tracefile_name
说明：
level 1 --dump controlfile header
level 2 --level 1+datafile 文件头信息
level 3 --level 2+可重用信息
level 10 --level 3+其他全部信息
此时控制文件头其中的内容如下：
*** 2024-09-03 16:31:05.011
Oradebug command 'setmypid' console output: <none>
DUMP OF CONTROL FILES, Seq # 1152 = 0x480
V10 STYLE FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=1706054720=0x65b05440, Db Name='ORCL'
Activation ID=0=0x0
Control Seq=1163=0x48b, File size=594=0x252
File Number=0, Blksiz=16384, File Type=1 CONTROL
*** END OF DUMP ***
--针对上面内容进行解释：
Compatibility Vsn: 表示具体的版本号
DB ID: 表示数据库的db id号
Db Name： 表示数据库的数据库名
Activation： 这里应该是dg有关，激活一次会加1
Control Seq： 表示control的sequence号
File size： 表示文件大小，这里但是是block(conrolfile block)
File Number: 在oracle内部，定义controlfile的文件号为0.
Blksize: 表示controlfile block的大小.
File Type: 表示文件类型.
--作者对比了下10g到23c 发现控制文件结构完全一样
既然知道controlfile header的各个部分的含义后，那么在有些针对controlfile损坏的情况下，甚至可以手工修复controlfile来解决问题。
除了dump controlfile之外，我们还可以利用操作系统命令dd+od来观察，如下：
dd if=/oradata/orcl/control01.ctl bs=16384 count=2 | od -x |head -500
--od -x 命令可以查看文件的16进制表示
0000000 c200 0000 0000 ffc0 0000 0000 0000 0000
0000020 f834 0000 4000 0000 0252 0000 7c7d 7a7b
0000040 81a0 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0040000 c215 0000 0001 0000 0000 0000 0000 0401
0040020 c055 0000 0000 0000 0400 0b20 5440 65b0
0040040 524f 4c43 0000 0000 048b 0000 0252 0000
0040060 4000 0000 0000 0001 0000 0000 0000 0000
0040100 0000 0000 0000 0000 0000 0000 0000 0000
*
0040140 1c87 65b6 08c0 463b ffc2 0011 0000 0000
0040160 fb19 4641 0000 0000 0000 0000 0000 0000
0040200 0000 0000 0000 0000 0000 0000 0000 0000
*
0040400 0000 0000 0000 0000 0008 0000 0008 0000
0040420 0008 0000 0000 0000 0000 0000 0000 0000
0040440 0001 0000 0000 0000 0000 0000 0000 0000
0040460 0000 0000 0000 0000 0000 0000 0000 0000
*
0077760 0000 0000 0000 0000 0000 0000 1501 0000
0100000
--下面针对上面dump 内容进行解析:
c2 表示type类型,转换后为194
4000 表示controlfile block size.(转换为10进制后为16384)
0252 表示文件大小,单位是block,转换为10进制后为594
7c7d 7a7b 表示操作系统平台的magic number号,每个操作系统对应的号码可能都不一样.
c215 是头部信息，这个不用关注
0001 表示file type.
0400 0b20 表示数据库版本号
5440 65b0 表示DB ID号
524f 4c43 0000 表示DB Name,如下：
SQL> select dump('ORCL',16) from dual;
DUMP('ORCL',16)
--------------------------------------------------
Typ=96 Len=4: 4f,52,43,4c
048b 表示controlfile sequence号 --这个号变化频繁，如果和dump不一致多做几次就能对上了
那么我们了解了这些信息之后，有什么用呢？
其实在很多针对controlfile损坏的情况下，如果你知道其结构内容,你甚至可以完全使用UE等工具去编辑，进行修复。从目前来看Oracle 10g到23c中控制文件头的结构是没有变化的。
对于控制文件中的其他section内容，我们要深入观察，我们仍然使用dump controlfile的方式来进行。
oradebug setmypid
ALTER SESSION SET EVENTS 'immediate trace name controlf level 3';
oradebug close_trace
oradebug tracefile_name
我们首先来看Controlfile dump其中最为重要的Database entry部分：
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
08/29/2024 10:19:44
DB Name "ORCL" --db name
Database flags = 0x00404001 0x00001200 --flags标识
Controlfile Creation Timestamp 08/29/2024 10:19:44 --这里是控制文件的创建时间
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.000e2006 Resetlogs Timestamp 08/29/2024 10:19:46
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/24/2013 11:37:30
Redo Version: compatible=0xb200400
#Data files = 5, #Online files = 5 --这里表示目前数据库中的datafile个数,以及处于online状态的文件个数.
Database checkpoint: Thread=1 scn: 0x0000.0011dc2b
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
..............
Max log members = 3, Max data members = 1 --表示目前数据库所允许的最大log member个数
Arch list: Head=2, Tail=2, Force scn: 0x0000.00119e2cscn: 0x0000.00000000
Activation ID: 1706054464
SCN compatibility 3
Auto-rollover enabled
Controlfile Checkpointed at scn: 0x0000.001201b1 09/03/2024 17:05:21
thread:0 rba:(0x0.0.0)
--下面我们来解析上面的内容:
size = 316 ---表示一个database entry record记录是316 byte大小.
compat size = 316 ---这部分表示database entry所占用的空间大小,单位是byte
section max = 1 ---表示该部分内容最大可用的section个数.
section in-use = 1 ---表示目前正在被使用的section数目.
extent = 1 ---表示该section片段占据的extent个数
blkno = 1 ---表示该section片段占据的block个数
numrecs = 1 ---表示该section片段占据的record记录数目
Resetlogs scn: 0x0000.000e2006 ---这里是表示resetlogs scn值. 转换后即为下面的timestamp值. Resetlogs Timestamp 08/29/2024 10:19:46
Prior resetlogs scn: 0x0000.00000001 ---这表示上次resetlogs 时的scn值.转换后即为下面的timestamp值. Prior resetlogs Timestamp 08/24/2013 11:37:30
Redo Version: compatible=0xb200400 ---该值表示数据库的的compatible值
Database checkpoint: Thread=1 scn: 0x0000.0011dc2b ---这里表示数据库thread checkpoint scn值.
Force scn: 0x0000.00119e2cscn ---这里表示force scn,在数据库或文件进行恢复时，会更新force scn.
Controlfile Checkpointed at scn: 0x0000.001201b1 09/03/2024 17:05:21 ---这里是表示控制文件检查点scn.不过这不是最新的值,该值是比较旧的. 当手工切换时或手工触发检查点，该值会更新.
接下来我们继续来看看checkpoint progress records section部分内容。
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:18
low cache rba:(0x1a.4921.0) on disk rba:(0x1a.4937.0)
on disk scn: 0x0000.001201fe 09/03/2024 17:07:33
resetlogs scn: 0x0000.000e2006 08/29/2024 10:19:46
heartbeat: 1178657809 mount id: 1706433671
#2 - status:0x0 flags:0x0 dirty:0
.............
THREAD #8 - 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
heartbeat: 0 mount id: 0
--下面我们开始进行解析：
size = 8180 ---表示一个database entry record记录是8180 byte大小.
compat size = 8180 ---这两部分表示database entry所占用的空间大小,单位是byte
section max = 11 ---表示该部分内容最大可用的section个数.
extent = 1 ---表示该section片段占据的extent个数
blkno = 2 ---表示该section片段占据的block个数
numrecs = 11 ---表示该section片段占据的record记录最大数目
status:0x2 ---表示该redo log是current状态(01表示active,0表示inactive)
dirty:18 ---表示该redo log所记录的脏块数目,不过是指data block.
low cache rba:(0x1a.4921.0) ---表示low rba值,该值是实例恢复的起点。
on disk rba:(0x1a.4937.0) ---表示on disk rba值,即实例恢复时,必须要恢复到的一个值.
on disk scn: 0x0000.001201fe 09/03/2024 17:07:33 ---表示on disk rba处的scn值.
resetlogs scn: 0x0000.000e2006 08/29/2024 10:19:46 ---表示上次resetlogs打开时的scn值.
heartbeat: 1178657809 ---这里是一个心跳值,每秒会变化一次,通过该机制来判断disk的状态.
mount id: 1706433671 ---表示磁盘加载时的一个标示,该值没有太大实际意义.
检查点结构中，我们重点关注是: low cache rba,on disk rba,on disk scn。
从上面Oracle 1g的dump 来看，检查点部分只有8个thread，说明Oracle 11g 应该只能最大支持8个数据库实例节点。
(本着好奇的态度，原作者dump了一下Oracle 23c，发现最大有32个thread了)
--我们继续来看redo thread section，这部分内容也是比较重要的.如下是dump的redo thread 信息:
***************************************************************************
REDO THREAD RECORDS
***************************************************************************
(size = 256, compat size = 256, section max = 8, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 9, numrecs = 8)
THREAD #1 - status:0xf thread links forward:0 back:0
#logs:3 first:1 last:3 current:2 last used seq#:0x1a
enabled at scn: 0x0000.000e2006 08/29/2024 10:19:46
disabled at scn: 0x0000.00000000 01/01/1988 00:00:00
opened at 09/03/2024 11:21:53 by instance orcl
Checkpointed at scn: 0x0000.0011dc2b 09/03/2024 11:21:53
thread:1 rba:(0x1a.aa2.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
......................
log history: 25
restore point keep sequence: 0
针对上述的内容，这里我们简单说明一下：
size = 256 ---表示一个database entry record记录是256 byte大小.
compat size = 256 ---这两部分表示database entry所占用的空间大小,单位是byte
section max = 8 ---表示该部分内容最大可用的section个数.
section in-use = 1 ---表示目前正在被使用的section数目.
logs:3 ---表示当前数据库有3个redo log组
first:1 ---表示当前写的redo log是第1组
last:3 ---表示上次写的redo log组编号
current:2 ---表示当前的日志组
last used seq#:0x1a ---表示当前的redo log sequence号. 转换后即为26
enabled at scn: 0x0000.000e2006 08/29/2024 10:19:46 ---表示eanbled scn,是开启flashback时的scn值.
Checkpointed at scn: 0x0000.0011dc2b 09/03/2024 11:21:53 ---表示开始写current log时的检查点scn值.
thread:1 rba:(0x1a.aa2.10) ---表示当前的线程rba值.
log history: 25 ----表示redo log切换了25次.这一点我们通过查询进行验证.
SQL> select count(1) from v$log_history;
COUNT(1)
----------
25
SQL> select group#,THREAD#,SEQUENCE#,status,next_time from v$log;
GROUP# THREAD# SEQUENCE# STATUS NEXT_TIME
---------- ---------- ---------- -------------------------------- -------------------
1 1 25 INACTIVE 2024-09-02 17:47:20
2 1 26 CURRENT
3 1 24 INACTIVE 2024-09-02 17:39:53
其中 Redo RBA 的是极其关键的，我们需要深入理解，其结构如下：
thread:1 rba:(0x1a.aa2.10)
0x1a --表示log sequence number,转换为10进制后为26,即当前的日志号
aa2 --block number,10进制是 2722 ,表示当前正在写第2722个block.
10 --byte number, 表示offset.
关于REDO THREAD RECORDS,就讲到这里,其中几个关键的地方大家要注意: Checkpointed at scn,thread rba。
我们继续来看 LOG FILE RECORDS 这部分内容。
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 3,
last-recid= 3, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
name #3: /oradata/orcl/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000019 hws: 0x3 bsz: 512 nab: 0x16a flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00119e2c
Low scn: 0x0000.0011d5e1 09/02/2024 17:39:53
Next scn: 0x0000.0011d776 09/02/2024 17:47:20
LOG FILE #2:
name #2: /oradata/orcl/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x0000001a hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0011d5e1
Low scn: 0x0000.0011d776 09/02/2024 17:47:20
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
name #1: /oradata/orcl/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000018 hws: 0x9 bsz: 512 nab: 0x7787 flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0011956e
Low scn: 0x0000.00119e2c 09/02/2024 11:39:28
Next scn: 0x0000.0011d5e1 09/02/2024 17:39:53
--关于这部分内容,也是比较重要的,注意是关于logfile的一些详细信息,下面我们对重点部分进行解析: 我们这里以LOG FILE #2 为例：
forward: 3 ---表现下一组将被写入的redo log是第3组.
siz: 0x19000 ---表示redo logfile block 个数,0x19000=102400个block
seq: 0x0000001a ---表示当前的sequence号
bsz: 512 ---表示其block size大小. 102400*512/1024/1024=50MB
Prev scn: 0x0000.0011d5e1 ---表示上组redo log写入时的起始scn值.
Low scn: 0x0000.0011d776 09/02/2024 17:47:20 ---表示该redo log写入时的起始scn值.
Next scn: 0xffff.ffffffff ---表示该redo log下一个scn值为无穷大,因为oracle不知道什么时候停止,所以会将该值设置为最大值,同时也说明该redo 是current 日志组.
接下来这部分是较为关键的 DATA FILE RECORDS 部分内容，很明显这部分会记录数据文件的一些重要信息，我们来看看具体包含了哪些？
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 5,
last-recid= 26, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
name #7: /oradata/orcl/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1 --这里表示其block大小,以及文件当前处于的状态等信息
tablespace 0, index=1 krfil=1 prev_file=0 --tablespace 0,表示其对应的v$tablespace.ts#号是0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:150 scn: 0x0000.0011dc2b 09/03/2024 11:21:53
Stop scn: 0xffff.ffffffff 09/02/2024 18:14:22
Creation Checkpointed at scn: 0x0000.00000007 08/24/2013 11:37:33
thread:0 rba:(0x0.0.0)
......
Offline scn: 0x0000.000e2005 prev_range: 0
Online Checkpointed at scn: 0x0000.000e2006 08/29/2024 10:19:46
thread:1 rba:(0x1.2.0)
......
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
--我们仍然针对其中的关键地方进行解析：
tablespace 0 ---表示其对应的v$tablespace.ts#号是0.
index=1 krfil=1 ---表示对应的数据文件号和相对文件号编号均为1.
Checkpoint cnt:1321 ---表示检查点记数,在数据库open时用于判断datafile是否过旧.
scn: 0x0000.0011dc2b 09/03/2024 11:21:53 ---表示datafile checkpoint scn值.
Stop scn: 0xffff.ffffffff ---表示数据文件的stop scn值,为最大值,说明数据库目前处于run状态(非正常关闭数据库的情况下,也是最大值)
Creation Checkpointed at scn: 0x0000.00000007 08/24/2013 11:37:33 ---表示创建该datafile时的scn.
Offline scn: 0x0000.000e2005 ---表示该数据文件offline时的scn值(每次DB关闭,都会更新该值).
Online Checkpointed at scn: 0x0000.000e2006 08/29/2024 10:19:46 ---表示该数据文件online时的checkpoint scn值.(每次数据库open都会更新该值)
rba:(0x1.2.0) ---表示线程rba信息.
status:0xe 表示文件状态status有如下几种值：
KCCFESTS 0x0001 * belongs to System TableSpace *
KCCFEONL 0x0002 * file is ONLine *
KCCFERDE 0x0004 * ReaDing is Enabled *
KCCFECGE 0x0008 * ChanGing is Enabled *
KCCFEMRR 0x0010 * Media Recovery Required *
KCCFEGEM 0x0020 * Generate End hot backup Marker at next open *
KCCFECKD 0x0040 * File entry generated by check dictionary *
KCCFESOR 0x0080 * Save Offline scn Range at next checkpoint *
KCCFERMF 0x0100 * Renamed Missing File *
KCCFEGOI 0x0200 * Generate Off-line Immediate marker *
--最后再来看看MTTR records和incarnation 部分
***************************************************************************
MTTR RECORDS
***************************************************************************
(size = 100, compat size = 100, section max = 8, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 160, numrecs = 8)
MTTR record for thread 1
MTTR statistics status: 1
Init time: Avg: 6494595 us, Times measured: 4 ---初始化的平均时间6.49s
File open time: Avg: 1219 us, Times measured: 14 ---文件打开平均时间0.001219s
Log block read time: Avg: 20 us, Times measured: 65536 ---log block的平均读取时间0.00002s
Data block read/claim time: Avg: 170 us, Times measured: 1000 ---数据块的平均读取时间为0.00017s
Data block write time: Avg: 390 us ---数据块的平均写入时间是0.00039s
1000 change vector apply time: Avg: 0 us, Times measured: 1
Ratio Information:
# of log blocks measured: 202025
# of data blocks measured: 7745
# of change vectors measured: 817377
对于Oracle MTTR，我们主要是了解到这个作用是什么，这里可以展开一下。
简单的讲，mttr是指Oracle实例崩溃之后实例恢复所完成所需要的时间；如果不设置mttr，那么有些系统在突然崩溃之后，实例重启到open的过程可能会很久，曾经见过30分钟才能open的数据库。
对于大型系统，我是建议设置一下MTTR的，通过设置mttr，Oracle 检查点跟进mttr设置进行相关计算，改变触发检查点的频率，从而避免Buffer cache中脏数据过多。
2年前曾经遇到的一个案例，我们认为可能就跟MTTRy有关，大家可以参：http://www.killdb.com/2022/11/22/oracle-instance-hung-due-to-gc-buffer-busy-acquire-gc-current-request/
--从作者这个案例我得到如下结论：
1>11g 大内存环境下如果session被阻塞的源头是lgwr进程
2> awr 报告中“physical writes non checkpoint”的值很接近 “physical writes from cache” 就需要调整MTTR参数了
最后来看incarnation records 部分，这部分跟数据库openresetlogs操作有关。
***************************************************************************
INCARNATION RECORDS
***************************************************************************
(size = 56, compat size = 56, section max = 292, section in-use = 2,
last-recid= 2, old-recno = 1, last-recno = 2)
(extent = 1, blkno = 141, numrecs = 292)
Earliest record:
RECID #1 Recno 1 Record timestamp
Resetlogs scn and time scn: 0x0000.00000001 08/24/13 11:37:30
Previous Resetlogs scn and time scn: 0x0000.00000000 01/01/88 00:00:00
Incarnation (parent inc#, flag)=(0, 0)
Latest record:
RECID #2 Recno 2 Record timestamp
Resetlogs scn and time scn: 0x0000.000e2006 08/29/24 10:19:46
Previous Resetlogs scn and time scn: 0x0000.00000001 08/24/13 11:37:30
Incarnation (parent inc#, flag)=(1, 2)
从上面内容，我们可以看到controlfile dump仅列出了最旧和最新的incarnation信息.(因为我dump的level 为3).
--RECID有两个：1和2
RECID #1 Recno 1 ---表示该记录对应的incarnation 编号.
Resetlogs scn and time scn: 0x0000.00000001 08/24/13 11:37:30 ---表示该次resetlogs操作时对应的scn值.
Previous Resetlogs scn and time scn: 0x0000.00000000 01/01/88 00:00:00 ---表示上上次resetlogs时的scn值.
-此时我的controlfile 中的incarnation 信息如下：
RMAN> list incarnation;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1706054720 PARENT 1 2013-08-24 11:37:30
2 2 ORCL 1706054720 CURRENT 925702 2024-08-29 10:19:46
这小节内容不多,但是需要大家引起重视。到最后，这节课内容就到此结束了，我们基本上把整个controlfile中的关键section信息都解析了一遍。
这样有助于彻底理解数据库的恢复,以及在某些特殊恢复的场景下去识别信息以及进行偷梁换柱来进行数据库恢复.
最后修改时间：2024-10-10 12:31:23
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
