從前面文章得知,當事務提交後會在資料塊中的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
***: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資訊.
UNDO自我理解總結
場景 當在更新資料的時候，發現更新的值寫錯了，這時就需要將已經更新的地方恢復到原始資料。基本概念 在更新的過程中，oracle會將原始的資料都放入到undo裡，這樣當以上情況發生後，就可以從undo中拿到原本的資料了。undo是在oracle 11g被提出的，由undo tablespace進行管理...
GBDT理解二三事
一 要理解gbdt當然要從gb gradient boosting 和dt decision tree 兩個角度來理解了 二 gb其實是一種理念，他並不是這乙個具體的演算法，意思是說沿著梯度方向，構造一系列的弱分類器函式，並以一定權重組合起來，形成最終決策的強分類器 注意，這裡的梯度下降法是在函式空...
AS3 onReleaseOutside 事件模擬
昨天聽群裡的朋友在討論as3 onreleaseoutside的問題,就寫了乙個.聽sephiroth說,他也寫過乙個,改天問他拿來看看.廣告,sephiroth是flash 3d程式設計高手 v 回到正題,as3裡onreleaseoutside事件移除了,as3幫助的對照表中,代替它的是mous...