從前面文章得知,當事務提交後會在資料塊中的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資訊.

請關注公眾號: