制造一些压力
create table testgp1
(id number(10),
name varchar2(20))
tablespace TESTO2;
同时开启2个会话
declare
i number(10);
begin
for i in 1..1000000
loop
insert into testgp1
values(i,'gp');
commit;
end loop;
end;
TRACE 文件目录/opt/oracle/admin/xuexi/udump/xuexi_ora_7525.trc
查看CONTROLFILE DUMP中的
***************************************************************************
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)
10/04/2013 22:10:43
DB Name "XUEXI"
Database flags = 0x00404001 0x00001000
Controlfile Creation Timestamp 10/04/2013 22:10:44
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.001d599f Resetlogs Timestamp 10/04/2013 22:14:48
Prior resetlogs scn: 0x0000.001d494d Prior resetlogs Timestamp 10/04/2013 21:54:38
Redo Version: compatible=0xa200100
#Data files = 10, #Online files = 10
Database checkpoint: Thread=1 scn: 0x0000.003b1f6c
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 ..00000000
Max log members = 3, Max data members = 1
Arch list: Head=3, Tail=11, Force scn: 0x0000.00399bacscn: 0x0000.003b1f6c
Activation ID: 2190560931
Controlfile Checkpointed at scn: 0x0000.003ca333 02/25/2015 08:56:47
***************************************************************************
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:887
low cache rba:(0x5f.be3b.0) on disk rba:(0x60.a4f.0)
on disk scn: 0x0000.003cada7 02/25/2015 08:56:49
resetlogs scn: 0x0000.001d599f 10/04/2013 22:14:48
heartbeat: 872565918 mount id: 2235198369
这里主要关注几个关键值
1、 Database checkpoint: Thread=1 scn: 0x0000.003b1f6c
2、 Controlfile Checkpointed at scn: 0x0000.003ca333 02/25/2015 08:56:47
3、 THREAD #1 - status:0x2 flags:0x0 dirty:887
low cache rba:(0x5f.be3b.0)
4、on disk rba:(0x60.a4f.0)
5、on disk scn: 0x0000.003cada7 02/25/2015 08:56:49
1、Database checkpoint: Thread=1 scn: 0x0000.003b1f6c
SCN应该代表的是LOW RBA的SCN，其实THREAD应该指的实例1，如果是RAC应该会出现多个，
关于这一点可以直接DUMP 0x5f.be3b.0的值进行看看其SCN值是否和此SCN对应
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
/opt/oracle/admin/xuexi/udump/xuexi_ora_7644.trc
SQL> ALTER SYSTEM DUMP LOGFILE '/oradata/xuexi/redo03.log' RBA MIN 95 48699 RBA MAX 95 48700;
System altered.
从TRACEFILE HRADER中我们获取了如下信息：
Low scn: 0x0000.003b1f6c (3874668) 02/25/2015 08:56:19
Next scn: 0x0000.003ca333 (3973939) 02/25/2015 08:56:47
可以看到这里确实是和Database checkpoint: Thread=1 scn: 0x0000.003b1f6c中的SCN是一致的
由此可以确定这实际是LOW RBA的SCN位置，这个位置及其重要是增量检查点完成到这里，也是每3秒
CKPT会去更新的。
这里想说明一下关于LOGFILE DUMP中的DBA BDBA HDBA
AFN:10 DBA:0x0280023f
bdba: 0x0280023f hdba: 0x02800011
实际上AFN:10 DBA:0x0280023f
这里就是修改的块的位置,这里文件序号是10，块的地址是0280023f
可以换算一下
SQL> select to_number('280023f','XXXXXXXX') from dual;
TO_NUMBER('280023F','XXXXXXXX'
------------------------------
41943615
SQL> SELECT dbms_utility.data_block_address_block(41943615) "BLOCK",
2 dbms_utility.data_block_address_file(41943615) "FILE"
3 FROM dual;
BLOCK FILE
---------- ----------
575 10
查看一下这个块属于哪个对象
SQL> SELECT segment_name,TABLESPACE_NAME FROM DBA_EXTENTS WHERE FILE_ID=10 AND 575 between block_id and block_id + blocks-1;
SEGMENT_NAME TABLESPACE_NAME
-------------------------------------------------------------------------------- ------------------------------
TESTGP1 TESTO2
如此可以看到确实是我们的testgp1表，对于BDBA和上面DBA一致，而HDBA应该是HEADER DBA的简写是SEGMENT HEADER.
2、Controlfile Checkpointed at scn: 0x0000.003ca333 02/25/2015 08:56:47
这个点从DSI中得到的信息如下：
Controlfile Checkpoint at SCN: It is updated after every checkpoint (may it be
tablespace, thread, or database) and is always greater than or equal to the database
checkpoint when the database is open.
可以看到他是进行了CHECKPOINT（不管full checkpoint还是增量检查点后更新的），我暂时理解为
增量检查点每次计算出来的目标点。
3、 THREAD #1 - status:0x2 flags:0x0 dirty:887
low cache rba:(0x5f.be3b.0)
这里重要就是DIRTY这应该是当前的脏数据量单位BLOCK，关于low cache rba:(0x5f.be3b.0)同1中的SCN
他们共同组成了当前增量检查点的对应的SCN和RBA，是如果出现CRAH RECOVERY的起点
4、on disk rba:(0x60.a4f.0)
5、on disk scn: 0x0000.003cada7 02/25/2015 08:56:49
这里代表是当前LOGFILE记录的RBA和SCN地址，在ORACLE中脏数据是DBWR进行写的，但是记录日志是LGWR的工作
每次COMMIT都会触发LGWR写，当然还有很多情况会触发，也就是想说明COMMIT的数据可能是脏数据，因为DBWR还没有
来得及写入。
至此可以断定进行CRAH RCEOVERY的时候实际上是Database checkpoint到on disk scn的日志量，他们都能找到对应的
RBA。
注：
RBA是日志序列.块地址.偏移量(就是日志块中的哪一行)组成的。