[oracle-ogg@oracleog archivelog]$dd if=/home/oralOg/oradata/siyang/redo02.log bs=512 skip=2 count=1|od一x
1+0 records in
1+0 records out
0000000 2201 0000 0002 0000 0021 0000 8010 f98a
0000020 030c 0000 120d 0000 da41 0070 0001 OOb7
这里的rba信息如下:
RBA:Ox000021.00000002.0010 rba的结构是由3部分组成的，如下:
rba=log sequence number(4 byte)+log block number(4 byte)+offset(2byte)
=21.2.10(注意，这是16进制的，我们需要转换为10进制)
=33.2.16
从rba的组成我们也可以发现，rba信息的长度是10个byte，分别是4-4-2.
下面我们将rba进行分解:
1.第一部分，21，为16进制，转换为10进制后为33.从上面信息，我们可以发现，我们的redo02当前的sequence号正好是33.
2.第二部分，2，为16进制，转换为10进制后为2.表示当前record记录在写入的是第2个redo block.
3.第三部分，10，为16进制，转换为10进制为16.表示该redo record记录的起始写位置是offset 16(即第2号block的第16个byte).
实际上每个block的一个redo record记录都是从offset 16开始写的，为什么呢?
问题:为什么?
前面我们讲过了，redo block header就占据了16个byte，而offset是从0开始，0~15就是16个offset(byte)，所以实际上
每个redo block里面的第一个redo record记录都是从第16个offset开始写的。
2)redo rba有哪几种?
实际上rba我们人为细分的话，可以分为如下几种:
low cache rba一最近一次cleanout block时，第一个block change时写的redo block address。
high rba一最近一次cleanout block时，最新的block change时写的redo block address
checkpoint rba一我们知道checkpoint queue上存放的脏块header是以low rba为顺序来的，dbwn进程在写
脏块的时候，就是根据checkpoint queue上的信息去写的。严格来讲这不算的rba信息，只是
检查点队列上的脏块信息是根据rba的先后顺序来排列的。这是针对dbwn进程来讲的。
on disk rba一这是针对Igwr进程来讲的。Igwr进行在写redo buffer时，低于on disk rba的redo信息都会被写入
到redo logfile中，实际上就是redo logfile的写入时的最末端位置。
实际上从low cache rba一&get; on disk rba的过程，就是前滚，所以on disk rba也就是实例恢复时前滚的终点。
target rba一也是指的checkpoint RBA，具体是指checkpoint结束时刻记录的rba地址。
我们知道ckpt进程会记录rba信息(checkpoint rba)，所以这里被称呼为target rbao
当然，你也可以理解为checkpoint target rba。
-------on disk rba
SQL> col "Low RBA" for a35
SQL> col "On disk RBA" for a35
SQL> set lines 200
SQL> select cpdrt,cplrba_seq||'.'||cplrba_bno||'.'||cplrba_bof "Low RBA",cpodr_seq||'.'||cpodr_bno||'.'||cpodr_bof "On disk RBA",
2 CPODS,CPODT,CPHBT from x$kcccp;
CPDRT Low RBA On disk RBA CPODS CPODT CPHBT
---------- ----------------------------------- ----------------------------------- ---------------- -------------------- ----------
933 237.3.0 237.12276.0 6241922 10/31/2018 10:02:22 990934191
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
0 0.0.0 0.0.0 0 0
8 rows selected.
QL> select lrba_seq,lrba_bno from x$bh where lrba_seq!=0 and rownum<20;
LRBA_SEQ LRBA_BNO
---------- ----------
237 7547
237 63
237 614
237 7547
237 9687
237 1412
237 7547
237 10816
237 11559
237 1412
237 7547
LRBA_SEQ LRBA_BNO
---------- ----------
237 127
237 4621
237 493
237 127
237 6544
237 7547
237 10816
237 7547
--------high rba
select hxfil,fhrba_seq,fhrba_bno,fhrba_bof,fhrba_seq||'.'||fhrba_bno||'.'||fhrba_bof "High RBA" from x$kcvfh;
SQL> select hxfil,fhrba_seq,fhrba_bno,fhrba_bof,fhrba_seq||'.'||fhrba_bno||'.'||fhrba_bof "High RBA" from x$kcvfh;
HXFIL FHRBA_SEQ FHRBA_BNO FHRBA_BOF High RBA
---------- ---------- ---------- ---------- --------------------------------------------------------------------------------------------------------------------------
1 237 2 16 237.2.16
2 237 2 16 237.2.16
4 237 2 16 237.2.16
5 237 2 16 237.2.16
6 237 2 16 237.2.16
--target rba
SQL> select target_rba_seq,target_rba_bno,target_rba_bof from x$targetrba;
TARGET_RBA_SEQ TARGET_RBA_BNO TARGET_RBA_BOF
-------------- -------------- --------------
0 0 0
可能会疑问，这个的seq 0,比当前的还小？这是正确的，为了保证进行前滚而设置的，
oracle会尽量设置一个靠前的值。跟oracle的几个参数有关系：
SQL> show parameter fast
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_io_target integer 0
fast_start_mttr_target integer 0
fast_start_parallel_rollback string LOW
3)redo rba有什么作用?oracle引入rba的目的是什么?
我们知道oracle dbwn进程在写脏块之前，必须要先分配redo buffer，以及undo，然后让更改记录(change vector)写入到redo buffer中
最后由Igwr进程将redo记录写入到logfile中。而redo记录写入的位置就是redo block address，也就是RBAo
当触发检查点时，ckpt进程也会记录rba信息，因为checkpoint queue上面的脏块列表也都是根据 rba的先后顺序来排序的。
这样可以保证dbwn进程写脏块的时候，可以顺序的写入。
既然这样，那么oracle在进行instance recovery时，是怎么来操作的呢?
我们知道实例恢复时，oracle会从controlfile中读取检查点信息，然后根据检查点信息定位到redo logfile中的具体位置，进而开始进行实例恢复。
我们前面已经知道checkpoint跟rba是息息相关的。实际上oracle也就是去搜索low cache rba地址，然后开始进行实例恢复，一直到on disk rba结束
完成整个实例的前滚操作。注意，这个时间点，数据库就可以open了，只是这个状态下的数据我们认为是不一致的，因为可能还有未提交
事务，可能已经写入到文件里面去了，oracle在应用redo时发现未提交的事务，会进行跳过，当数据库open之后，利用undo去回滚未提交事务(实际上是去检查undo事务表
确认那些事务是未提交的)，后面我们会详细描述undo方面的内容，这里先不多说。
所以，我们不能说on disk rba就是实例恢复的终点。
阅读(2514) | 评论(0) | 转发(0) |
