4.DUMP数据文件查看CHECKPOINT_CHANGE#/RBA，与DUMP控制文件对比
更详细DUMP数据文件方式见：http://blog.csdn.net/q947817003/article/details/16369041SYS@ bys3>alter system set events 'immediate trace name file_hdrs level 3'; --最好和上一步DUMP控制文件在不同的会话
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
----------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1010.trc
查看TRACE文件： --截取部分内容--
Tablespace #4 - USERS rel_fn:4Creation at scn: 0x0000.000034f9 11/14/2013 14:26:26
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x318f5cd7 scn: 0x0000.00000001
prev reset logs count:0x0 scn: 0x0000.00000000
recovered at 12/02/2013 13:17:26
status:0x4 root dba:0x00000000 chkpt cnt: 168 ctl cnt:167
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001e6231 12/02/2013 13:17:26 -------数据文件中检查点计数cnt:168比控制文件中Checkpoint cnt:167 多1，检查点 scn: 0x0000.001e6231与前文吻合
thread:1 rba:(0x6b.2.10) --------REDO日志的地址0x6b.2.10--－> 107号日志，第2号块，第16个字节
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Backup Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 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 01/01/1988 00:00:00
Platform Information: Creation Platform ID: 10
Current Platform ID: 10 Last Platform ID: 10
DUMP OF TEMP FILES: 1 files in database
第3步中：《《注意：
从控制文件中得到重做日志恢复起始地址如下：
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0)
实例恢复的起点：107号日志，第3个块，第0个字节
--on disk rba:(0x6b.197.0)：
实例恢复的终点：107号日志，第407个块，第0个字节 --具体是不是终点，最后讨论
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37
数据库恢复的检查点终点是SCN--0x0000.001e638d，十进制是：1991565。
On-Disk RBA的SCN是1991565，这是实例恢复的终点。
数据库的恢复SCN范围也就由此确定，即SCN范围：最后检查点：1991217--On-Disk RBA，用SCN表示即：1991217 ===>>>1991565》》
--说明：
实例恢复的起点是Low Cache RBA和Thread Checkpoint RBA中的最大值，实例恢复的终点就是current redo log file的最尾端而不是On-Disk RBA。
这样，本实验中实例恢复的起始的重做日志是以控制文件中的low cache rba:(0x6b.3.0)开始恢复，而不是从文件头的thread:1 rba:(0x6b.2.10)
########################################################################
5.DUMP REDO日志文件 --在第一步已经确定了当前日志是redo02.log
更详细方法，见：http://blog.csdn.net/q947817003/article/details/16370203SYS@ bys3>alter system dump logfile '/u01/oradata/bys3/redo02.log';
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1906.trc
REDO日志DUMP最后一个REDO RECORD 的一部分CHANGE #1： --不知道如何解读，留白吧？？？
REDO RECORD - Thread:1 RBA: 0x00006b.00000194.0084 LEN: 0x0418 VLD: 0x09
SCN: 0x0000.001e638c SUBSCN: 1 12/02/2013 13:21:37
CHANGE #1 TYP:2 CLS:1 AFN:1 DBA:0x004007e1 OBJ:288 SCN:0x0000.001e6386 SEQ:2 OP:11.5 ENC:0 RBL:0
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0009.017.00000642 uba: 0x00c00cac.00f9.28
Block cleanout record, scn: 0x0000.001e638b ver: 0x01 opt: 0x02, entries follow...
itli: 2 flg: 2 scn: 0x0000.001e6386
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x0