什么是rba ?
脏数据块 改对应的redo记录条目的位置
rba包括哪些内容?
- 条目所在redo文件的sequence号
- 条目所在日志文件的块号
- 条目距离日志文件开始位置的偏移量
rba的分类
- low rba :在buffer cache中的数据块第一次数据改变所对应的RAB。 脏数据块在检查点 队列里面按照low rba排列。
- high rba :在buffer cache中的数据块最近一次数据改变时所对应的RAB。
- checkpoint rba:在checkpint queue中(每次checkpoint queue被clean以后)第一个脏数据块第一次被修改对应的RAB,这个RBA之前的脏数据已经被全部写入磁盘。
- on-disk rba:是 lgwr 写日志文件的最末位置的地址。
数据库 实例恢复 的范围
从checkpoint RBA 到on-disk RBA 的 充作记录。8i所引入的增量检查点每隔三秒钟或发生日志切换时启动。它启动时只做一件事情:找出当前检查点队列上的第一个buffer header,并将该buffer header中所记录的LRBA(这个LRBA也就是checkpoint position了)记录到控制文件中去(checkpoint RBA )。而on-disk RBA 是 lgwr 写日志文件的最末位置的地址。
与rba相关的数据字典
X$BH 用于查看脏块的LRBA和HRBA(There is also a recovery RBA which is used to record the progress of partial block recovery by PMON)
X$TARGETRBA 查看
增量checkpoint RBA
,target RBA和on-disk RBA。
X$KCCCP 这里面
也有增量checkpoint RBA,target RBA的信息。
X$KCCRT 完全checkpoint(full thread checkpoint)RBA信息
注释:
X$TARGETRBA和X$KCCCP 两个视图里的 增量checkpoint RBA 字段的值 来自控制文件里的CHECKPOINT PROGRESS RECORDS条目中的low cache rba。The checkpoint RBA(即low cache rba) is the point up to which DBWn has written buffers from the checkpoint queues if incremental checkpointing is enabled -- otherwise it is the RBA of last full thread checkpoint.
疑问:recovery RBA和target RBA是什么意思,什么作用?
附加:
Redo Byte Address (RBA)
Recent entries in the redo thread of an Oracle instance are addressed using a 3-part redo byte address, or RBA. An RBA is comprised of
- the log file sequence number (4 bytes)
- the log file block number (4 bytes)
- the byte offset into the block at which the redo record starts (2 bytes)
RBAs are not necessarily unique within their thread, because the log file sequence number may be reset to 1 in all threads if a database is opened with the RESETLOGS option.
RBAs are used in the following important ways.
With respect to a dirty block in the buffer cache, the
low RBA is the address of the redo for the first change that was applied to the block since it was last clean, and the
high RBA is the address of the redo for the most recent change to have been applied to the block.
Dirty buffers are maintained on the buffer cache checkpoint queues in low RBA order. The checkpoint RBA is the point up to which DBWn has written buffers from the checkpoint queues if incremental checkpointing is enabled -- otherwise it is the RBA of last full thread checkpoint. The checkpoint RBA is copied into the checkpoint progress record of the controlfile by the checkpoint heartbeat once every 3 seconds. Instance recovery, when needed, begins from the checkpoint RBA recorded in the controlfile. The target RBA is the point up to which DBWn should seek to advance the checkpoint RBA to satisfy instance recovery objectives.
The on-disk RBA is the point up to which LGWR has flushed the redo thread to the online log files. DBWn may not write a block for which the high RBA is beyond the on-disk RBA. Otherwise transaction recovery (rollback) would not be possible, because the redo needed to undo a change is always in the same redo record as the redo for the change itself.
The term sync RBA is sometimes used to refer to the point up to which LGWR is required to sync the thread. However, this is not a full RBA -- only a redo block number is used at this point.
The low and high RBAs for dirty buffers can be seen in X$BH. (There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.) The incremental checkpoint RBA, the target RBA and the on-disk RBA can all be seen in X$TARGETRBA. The incremental checkpoint RBA and the on-disk RBA can also be seen in X$KCCCP. The full thread checkpoint RBA can be seen in X$KCCRT.
========================================================
low cache rba就是CKPT记录的DBWR(在Checkpoint Queue上)写(脏块)的进度, on disk rba就是LGWR的写进度.
low cache rba 以前的更新的脏块已经写入数据文件,不需要重做, on disk rba以后的日志还没写入到online logfile.所以不需要恢复.
【
恢复到 on-disk rba,而不是 high rba(high rba 一般情况下会大于 on-disk rba,但是因为 high rba 比 on-disk rba 多的部分记录在
redo log buffer 中,在实例恢复的时候,因为其未被记录到 redo log file 中,所以不能被恢复,其实也没有必要恢复,因为该数据
肯定是没有 commit 或者 rollback。
】
low cache rba和on disk rba记录在控制文件的CHECKPOINT PROGRESS RECORDS条目中。
实验如下:
SQL> create table anran(id int)
2 /
表已创建。
SQL> insert into anran values(7)
2 /
已创建 1 行。
SQL> commit
2 /
提交完成。
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 603979776 bytes
Fixed Size 1298112 bytes
Variable Size 171966784 bytes
Database Buffers 423624704 bytes
Redo Buffers 7090176 bytes
数据库装载完毕。
SQL> oradebug setmypid
已处理的语句
SQL> oradebug dump controlf 4
已处理的语句
打开控制文件找到CHECKPOINT PROGRESS RECORDS:
***************************************************************************
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:32
low cache rba:(0x12.5c85.0) on disk rba:(0x12.5ced.0)
on disk scn: 0x0000.001414d0 07/09/2010 00:06:12
resetlogs scn: 0x0000.000fffeb 07/05/2010 11:10:48
heartbeat: 723882252 mount id: 886034360
....
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
只有Thread 1 是对我们有用的。其中
low cache rba:(0x12.5c85.0) 0x12.5c85.0 = 18.23685.0
on disk rba:(0x12.5ced.0) 0x12.5ced.0 = 18.23789.0
【
即使low cache rba和on disk rba不相等,也不一定说明一定要进行实例恢复,比如delete from t where 1=2;则没有一行实际被删除,即该sql语句操作对应的redo记录里没有涉及到修改的数据块。low cache rba和on disk rba之间的redo记录假如都是这种情况,则就没有需要恢复的数据块,故不用实例恢复。不过实例恢复的过程还是有的?
】
SQL> alter database open;
数据库已更改。
查看alert.log可以看到:
Beginning crash recovery of 1 threads
parallel recovery started with 2 processes
Fri Jul 09 00:12:54 2010
Started redo scan
Fri Jul 09 00:12:55 2010
Completed redo scan
104 redo blocks read, 34 data blocks need recovery
Fri Jul 09 00:12:55 2010
Started redo application at
Thread 1:
logseq 18, block 23685 ---恢复起点
Fri Jul 09 00:12:55 2010
Recovery of Online Redo Log: Thread 1 Group 1 Seq 18 Reading mem 0
Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ANRAN\ONLINELOG\O1_MF_1_63007KDR_.LOG
Mem# 1: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ANRAN\ONLINELOG\O1_MF_1_63007J6X_.LOG
Fri Jul 09 00:12:55 2010
Completed redo application
Fri Jul 09 00:12:55 2010
Completed crash recovery at
Thread 1:
logseq 18, block 23789, scn 1336048
---恢复终点
34 data blocks read, 32 data blocks written, 104 redo blocks read.