dml操作时，undo究竟是如何工作的（二）？

接上一篇

转储前镜像信息：

第一个session对应的前镜像的dba0x008000a8，将此转换为2进制，其中前十位代表文件号，后24为代表块号，正好是文件号2的第168块，第二个session对应的前镜像dba 0x0080000a，对应file 2 block 10，此结果和从v$transaction查询的ubafil,ubablk相符。

继续在session中insert一笔记录

SQL> insert into emp(empno,ename,sal) values (9999,'klj',8868);

已创建1行。

在session 2中delete一笔记录

SQL> delete emp where empno=7902;

已删除1行。

开始转储前镜像

SQL> alter system dump datafile 2 block 168;

System altered

SQL> alter system dump datafile 2 block 10;

System altered

并分别重命名为undo_block_before_commit_session1，undo_block_before_commit_session2

session1的前镜像转储文件简要如下

********************************************************************************

UNDO BLK: 

xid: 0x000a.02b.00000134 seq: 0x3e cnt: 0x22 irb: 0x22 icl: 0x0  flg: 0x0000

 Rec Offset     Rec Offset     Rec Offset     Rec Offset     Rec Offset

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

0x01 0x1fb4    0x02 0x1f64    0x03 0x1f14    0x04 0x1ee0    0x05 0x1e90    

0x06 0x1e40    0x07 0x1e0c    0x08 0x1dbc    0x09 0x1d6c    0x0a 0x1d38    

0x0b 0x1ce8    0x0c 0x1c98    0x0d 0x1c64    0x0e 0x1c14    0x0f 0x1bc4    

0x10 0x1b90    0x11 0x1b40    0x12 0x1af0    0x13 0x1abc    0x14 0x1a6c    

0x15 0x1a1c    0x16 0x19e8    0x17 0x1998    0x18 0x1948    0x19 0x1914    

0x1a 0x18c4    0x1b 0x1874    0x1c 0x1840    0x1d 0x17f0    0x1e 0x17a0    

0x1f 0x176c    0x20 0x1704    0x21 0x16c4    0x22 0x1684

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

* Rec #0x20 slt: 0x2b objn: 30139(0x000075bb) objd: 30139 tblspc: 0(0x00000000)

*      Layer: 11 (Row)  opc: 1  rci 0x00  

Undo type: Regular undo   Begin trans   Last buffer split: No

Temp Object: No

Tablespace Undo: No

rdba: 0x00000000

*-----------------------------

uba: 0x008000a8.003e.1f ctl max scn: 0x0000.00059108 prv tx scn: 0x0000.00059112

KDO undo record:

KTB Redo

op: 0x03 ver: 0x01 

op: Z

KDO Op code: URP row dependencies Disabled

 xtype: XA bdba: 0x0040c522 hdba: 0x0040c521

itli: 2 ispac: 0 maxfr: 4863

tabn: 0 slot: 6(0x6) flag: 0x2c lock: 0 ckix: 0

ncol: 8 nnew: 1 size: 1

col 5: [ 3] c2 19 33

*-----------------------------

* Rec #0x21 slt: 0x2b objn: 30139(0x000075bb) objd: 30139 tblspc: 0(0x00000000)

*      Layer: 11 (Row)  opc: 1  rci 0x20  

Undo type: Regular undo  Last buffer split: No

Temp Object: No

Tablespace Undo: No

rdba: 0x00000000

*-----------------------------

KDO undo record:

KTB Redo

op: 0x02 ver: 0x01 

op: C uba: 0x008000a8.003e.20

KDO Op code: DRP row dependencies Disabled

 xtype: XA bdba: 0x0040c522 hdba: 0x0040c521

itli: 2 ispac: 0 maxfr: 4863

tabn: 0 slot: 14(0xe)

*-----------------------------

* Rec #0x22 slt: 0x2b objn: 30140(0x000075bc) objd: 30140 tblspc: 0(0x00000000)

*      Layer: 10 (Index)  opc: 22  rci 0x21  

Undo type: Regular undo  Last buffer split: No

Temp Object: No

Tablespace Undo: No

rdba: 0x00000000

*-----------------------------

index undo for leaf key operations

KTB Redo

op: 0x03 ver: 0x01 

op: Z

Dump kdilk : itl=3, kdxlkflg=0x1 sdc=0 indexid=0x40c529 block=0x0040c52a

purge leaf row

key :(4): 03 c2 64 64

其中xid=undo segment number+transaction table solt +wrap

irb表示最新未提交的开始位置，回滚将从这里开始。

Undo recoder中rci表示同一事物中的上一条需要回滚的记录。

Bdba代表了该记录的数据块地址

在session1前镜像中同样存在对应数据块的地址，bdba: 0x0040c522对应为file 1 block 50466

，同样在session 2的前镜像中也存在对应数据库的地址bdba: 0x0040c522，对应为file 1 block 50466，转储该数据块

SQL> alter system dump datafile 1 block 50466;

System altered

重命名data_block_before_commit_sessino1&session2，其中的itl（interested transaction list itl）事务槽信息如下，和undo block中的xid完全一致。

Itl          Xid                 Uba        Flag Lck       Scn/Fsc

0x01  0x0001.015.00000135 0x0080000a.0042.28 ----   2 fsc 0x0025.00000000

0x02  0x000a.02b.00000134 0x008000a8.003e.21 ----   2 fsc 0x0000.00000000

xid=undo.segment.number + transaction_table_solt.number +wrap

uba=udba +seq+irb ????

lb lock byte行锁定标志，再更新记录前，需要加锁

接下来查看lb=0x2即第一个session update和insert的记录

tab 0, row 6, @0x1a40

tl: 40 fb: --H-FL-- lb: 0x2 cc: 8

col 0: [ 3] c2 4e 53

col 1: [ 5] 43 4c 41 52 4b

col 2: [ 7] 4d 41 4e 41 47 45 52

col 3: [ 3] c2 4f 28

col 4: [ 7] 77 b5 06 09 01 01 01

col 5: [ 2] c2 33

col 6: *NULL*

col 7: [ 2] c1 0b

………………………………….

………………………………….

………………………………….

tab 0, row 14, @0x1a2e

tl: 18 fb: --H-FL-- lb: 0x2 cc: 6

col 0: [ 3] c2 64 64

col 1: [ 3] 6b 6c 6a

col 2: *NULL*

col 3: *NULL*

col 4: *NULL*

col 5: [ 3] c2 59 45

col 5: [ 2] c2 33 表示update的5000，col 5: [ 3] c2 59 45就是8868

继续找lb为0x1，表示为第二个session锁定的行

tab 0, row 10, @0x1c7e

tl: 38 fb: --H-FL-- lb: 0x1 cc: 8

col 0: [ 3] c2 4f 4d

col 1: [ 5] 41 44 41 4d 53

col 2: [ 5] 43 4c 45 52 4b

col 3: [ 3] c2 4e 59

col 4: [ 7] 77 bb 05 17 01 01 01

col 5: [ 2] c2 2e

col 6: *NULL*

col 7: [ 2] c1 15

………………………………….

………………………………….

………………………………….

tab 0, row 12, @0x1cca

tl: 2 fb: --HDFL-- lb: 0x1

col 5: [ 2] c2 2e 即为4500。

Commit之后的回滚段和数据块

Commit之后，回滚段事务表标记为非活动，但回滚段数据块的信息在没有重用前依然存在。

对于数据块，如果做得是快所块清除（fast block cleanout）,则同时清除itl事务槽，行级锁lb信息，如果是延迟块清除（delayed block cleanout）,处理起来要复杂点，要等到下一次访问到该块的时候再做块清除（这也是为什么select语句会有redo的原因）