从前面文章得知,当事务提交后会在数据块中的ITL该XID 标帜字段FLAG 打上C,并在SCN/FCN字段上打上自己提交的SCN.
如果说当一个事务更新了1万个块,更新时间比如说30分钟.
这个时候会因为DBWR把被更新的数据块写回磁盘中.
假如提交的时候已经有8千个块写入了磁盘.那么做提交命令的时候,需要把块上的XID信息修改下,如上面的动作一样,还有解除行上的锁字节. 那么是否要把写进磁盘的8000个块再次读入到内存中进行事务修改呢?
ORACLE 为了性能 做了下面三个步骤完成提交 修改事务的动作
一 如果块比较少,都在内存中未被写入磁盘,那么做个完整的事务提交修改工作.
二 部分或者大部分写入磁盘的话,先做还在内存中的块事务提交修改工作,在FLAG上打上U标帜,并写入SCN. 并设置会话内存中的10%为保留值,保留多少修改的块. 实际上是个列表.
三 对已经写入磁盘的块,做延迟块清除(延迟事务提交工作). 就是说等下个回话读取该块的时候做.
这里要牢记一点就是 数据块里的ITL,UNDO段里的ITL,以及UNDO块 都会被重用,被覆盖掉.
当从磁盘读取块的时候,发现有些事务没有提交,那么拿着事务XID去UNDO里面找,如果找到了就把该事务的SCN写入数据块ITL对应的信息中.
如果找不到呢? 这个时候表示UNDO段的ITL被重用了,同样事务被重用之前,新事务会把ITL信息登记在自己UNDO块中记录里面,这个记录在事务的首条记录里面.
不过UNDO段的ITL里面没有跟数据块UBA字段. 这个字段被移植到事务控制区中. 事务控制区有关ITL槽号被重用的信息.
信息字段如下
seq: 0x08f5
chd:0x00b
ctl:0x0017
inc:0x000000
nfb:0x0001
mgc:0xb000
xts:0x0068
flg:0x0001
opt:2147483646(0x7ffffffe)
uba:0x180120f.08f5.24
scn:0x0000.018bc75e
其他字段不重要,重要是UBA和SCN. SCN是最近重用时被覆盖的前事务的提交的SCN. UBA指向前前的链条指针.也就是事务开始的首条UNDO记录.
uba:0x0180120f.8f5.21 ctl max scn:0x0000.018bc704
prv tx scn:0x0000.018bc75e
txn start scn :scn: 0x0000.018bcd3e logon user:86
prev brb:25170445 prev bcl:0
prv tx scn:0x0000.018bc75e <=表示被覆盖的提交SCN
txn start scn :scn: 0x0000.018bcd3e <=表示事务开始的SCN
prev brb:25170445 <=十六进制是0x0180120D 事务最后的UNDO块地址
这里DUMP出来的结构信息好像少了个WRAP#值. 没关系我们理解原理. 通过事务的首条unod记录里面的uba 地址 可以追溯更早被覆盖的Undo段的ITL信息.
请关注公众号: