其实很早就掌握了redo internal,Redo是oracle的灵魂,在此分享下:

---------------------------------

1.Index Insert 10.2+commit(5.4)
2.Index update = 10.4 + 10.2 + commit(5.4)
3.Index delete = 10.4 +commit(5.4)
4.Conditional Index Update  = row_optios+index_options
包括表row操作+索引Index操作

table t(id number)                              -->表列
index t(id)                                     -->表列的索引
SQL> select * from t;
 
                                     C1
---------------------------------------
                                      1
                                     

                              step1                          step2                       step3                       step4     
Before/After                  1/2                            1/1                         1/null                      null/1
DMS statement                 update  t                      update t set                update t set                update t
                              set c1 = 2 where c1 = 1        c1=1 where c1=1             c=null where c1=1           set c1=1 where c1=null
                                                            
Update table row(11.5)       undo#1    5.1                   undo#1 5.1                  undo#1  5.1                 undo#1  5.1
                             redo#1    11.5                  redo#1 11.5                 redo#1  11.5                redo#1  11.5
Del Index row(10.4)          undo#2    5.1                   No                          undo#2  5.1                 No
                             redo#2    10.4                  No                          redo#2  10.4                No
Inst Index row(10.2)         undo#3    5.1                   No                          No                          undo#3 5.2
                             redo#3    10.2                  No                          No                          redo#3 10.2                                              -->为什么是redo#3,可能会越过2一些操作?
                            注.commit;ver#=ver_id,5.1=(undo head表示该事务要记录到undo中,表示事务的表更新slot号);一个ver#代表一个事务;redo#表示具体操作
                              .详细见附录

如果是insert的话则是11.2(原理一样)

Step1.表示将索引列的值从非null更新到不同的非null时,首先有row_update(11.5),然后10.4(del_index_row),最后10.2(insert_index_row)
Step2.表示将索引列的值从非null更新到相同的非null时,只有row_update(11.5),没有索引操作index_options(就是说不会产生回滚和重做信息,即所谓的数据没有更改)
Step3.表示将索引列的值从非null更新到null时,首先有row_update(11.5),然后10.2(del_index_row)删除索引行,不会10.2(即在该情况下不会增加索引行index_row)
Step4.表示将索引列的值从null更新到非null索引列时,首先是row_update(11.5),跳过del_index_row(10.4),直接insert_index_row(10.2),中间没有del_index_row操作

总结
*.如果是DML操作(事务),则redo record头都会有#layer=5的代表事务的开始,而非事务则没有会是其他的layer同时change# vector只有一个
*.在Redo record header p=5时(DML开始的标志),Record vector change#代表一个事务,change#递增代表事务是持续的,也就是对同一个块的更改
*.DML事务(每个vector#)都包含undo#和redo#,他们成对出现,用于记录事物的详细过程,来记录对数据库的更改
*.对包含index列的更新时,都会有11.5的操作(行更数据行11.5=row_delete+row_insert)            
*.事务结束redo vector change# p=5.4
*.null对索引的影,即索引不会与null值有相联系的趋向
*.更新索引列数据时,索引也会相应的更新,当索引建得太多的时候,更新列将会有更多的索引行(index_row)操作,会造成更新很慢等结果,索引的level更新会改动索引最后一次更新的sort顺序,影响整体性能,因为会产生很多的undo#和redo#
*.DML事务都有undo#,redo#,每个vector#代表一个block更改,那么就可以解释undo为什么能够rollback到某个时间点(SCN),以及读一致性的原理
(四.三)Block Cleanout(块清除)
Occurs when ITL on data block has not been updated when changes were committed
在change commit的时候该数据库块内的ITL并没在undo segment header(该事务的SLOT在undo segment header的事务表没有更新,即commit事物结束而ITL还在表示事物进行)更新时出现
Block Cleanout redo
   *.Can be generated by SELECT statements             --Block cleanout可以由Select 产生,也就是说select语句可以产生redo,因为该情况下有block cleanout 发生
   *.Opcode 4.1
   *.requires 60 byte redo record for each block

eg:
---------------
REDO RECORD - Thread:1 RBA: 0x000080.00013c74.0010 LEN: 0x02ec VLD: 0x0d
SCN: 0x0000.00299b76 SUBSCN:  1 10/31/2009 14:48:43
CHANGE #1 TYP:2 CLS: 1 AFN:4 DBA:0x01000d3d OBJ:43809 SCN:0x0000.00299b70 SEQ:  2 OP:11.5
KTB Redo
op: 0x11  ver: 0x01 
op: F  xid:  0x0007.011.0000023d    uba: 0x0080101c.00ba.14
Block cleanout record, scn:  0x0000.00299b74 ver: 0x01 opt: 0x02, entries follow...                              -->block cleanout
  itli: 2  flg: 2  scn: 0x0000.00299b70
KDO Op code: URP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x01000d3d  hdba: 0x01000d3b
itli: 1  ispac: 0  maxfr: 4858
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 1 ckix: 0
ncol: 1 nnew: 1 size: 3
col  0: [ 2]  c1 02
------------------

 

(四.四)Hot backup about redo(热备)
1.When hot backups are in use(logging), when backup mode is enabled as:                                 -->开始热备
ALTER TABLESPACE BEGIN BACKUP
*.A block image is written to the redo log for each block that is modified (opcode 18.1),eg:            -->在备份期间,在该表空间的所有被修改的块的镜像被写在redo log中
-------------
REDO RECORD - Thread:1 RBA: 0x003e3b.00000005.0010 LEN: 0x0818 VLD: 0x01
SCN: 0x0000.0ac84345 SUBSCN:  1 06/27/2003 15:06:06
CHANGE #1 TYP:3 CLS: 1 AFN:5 DBA:0x014343c2 SCN:0x0000.0ac8433d SEQ:  1 OP:18.1
Log block image redo entry                                                                              -->开始的image标志
---------------
2.When backup mode is disabled as :
ALTER TABLESPACE END BACKUP;                                                          -->备份结束
*.an end backup marker is written to redo log (17.1)
-----------------
REDO RECORD - Thread:1 RBA: 0x003e3b.0000000c.0010 LEN: 0x0038 VLD: 0x01
SCN: 0x0000.0ac84347 SUBSCN:  1 06/27/2003 15:06:09
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:17.1
End backup marker - file:5 scn:  0x0000.0ac84341                                                       -->结束的image标志         
----------------

(四.五)Block Write(块写)
*.In Oracle 9.0.1 and above blocks written from buffer cache to disk by DBWR are recorded in redo logs
*.Supports fast recovery
*.Each block record is 32 bytes in length (OS dependent
--------------------
REDO RECORD - Thread:1 RBA: 0x000080.000130e1.0024 LEN: 0x00b4 VLD: 0x02
SCN: 0x0000.00299344 SUBSCN:  1 10/31/2009 13:56:26
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:23.1
 Block Written - afn: 4 rdba: 0x01000d39 BFT:(1024,16780601) non-BFT:(4,3385)                          -->Block written
                   scn: 0x0000.002992da seq: 0x02 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d3a BFT:(1024,16780602) non-BFT:(4,3386)                          -->Block written
                   scn: 0x0000.002992b2 seq: 0x01 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d3b BFT:(1024,16780603) non-BFT:(4,3387)
                   scn: 0x0000.002992da seq: 0x02 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d3c BFT:(1024,16780604) non-BFT:(4,3388)
                   scn: 0x0000.002992da seq: 0x01 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d3d BFT:(1024,16780605) non-BFT:(4,3389)
                   scn: 0x0000.002992da seq: 0x03 flg:0x06
 Block Written - afn: 4 rdba: 0x01000d3e BFT:(1024,16780606) non-BFT:(4,3390)
                   scn: 0x0000.002992da seq: 0x01 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d3f BFT:(1024,16780607) non-BFT:(4,3391)
                   scn: 0x0000.002992da seq: 0x01 flg:0x04
 Block Written - afn: 4 rdba: 0x01000d40 BFT:(1024,16780608) non-BFT:(4,3392)
                   scn: 0x0000.002992da seq: 0x01 flg:0x04