關於延遲塊清除的原理是什麼?為什麼要進行塊清除

　　論壇上有人問這樣一個問題，我以前也是不是太理解，只知道當一個大的事務需要處理的時候，進行延遲塊清除，這樣加快處理速度．但是今天感覺這個解釋比較容易理解．

delay block cleanout :
主要針對大事務，可能在commit的時候，一些資料髒快已寫入資料檔案，提交時，無法把這些資料塊標記commit,該資料塊的下一個讀者對其進行delay block cleanout 。資料塊的下一個讀者首先檢查該塊的事務狀態是否為活動，不活動的話，修改事務的標誌（flag)。這樣可以避免不必要的事務讀。

對於為什麼要用最小的scn更新itl，對於查詢安全要怎麼理解 ：

commit 的時候沒有來得及更改這個block（delay block cleanout），事後cleanout 的時候已經找不到當時對應的scn了，但是，從回滾段中可以得到一個最小的提交scn並且該事務已經提交肯定小於這個從回滾段中還存在的最小scn。那麼oracle給這個 cleanout 的事務分配一個從回滾段中找到的最小事務scn。這雖然不準確，但是是安全的，對於資料訪問也不構成影響。所以叫 upper bound ,猜測的一個scn的上限。

cleanout分為2鍾，一種是fast commit cleanout,另一種是delayed block cleanout.
oracle有一個modified block list結構，用來記錄每個transaction更改過的block，每個transaction大約可以記錄10%buffer cache這多的modified block。（即為每個事務可記錄的modified block大約是buffer cache的10%）這部分block就是當發生commit的時候，oracle可以根據modified block list定位到那些塊並做fast commit cleanout。如果一個transaction修改的塊超過10% buffer cache,那麼超過的塊就執行delayed block cleanout。當做fast commit cleanout時，oracle不會清理 Row locks lb標誌位，ITL lck標誌位。
另一種情況是delayed block cleanout，當transaction還未commit或rollback時modified block已經被寫回磁碟，當發生commit時oracle並不會把block重新讀入做cleanout，而是把cleanout留到下一次對此塊的dml或select。當delayed cleanout時候如果undo segment header的transaction table slot還沒有被覆蓋，那麼可以找回該事務遞交的exact scn，如果slot已經被覆蓋，那麼將會使用undo segment header中的control scn來做為upper bound scn。

針對讀一致性考慮：

每個資料頭部都會記錄一個提交ＳＣＮ，當資料更改提交後，提交scn同時被修改，這個scn在查詢時可以用來進行一致性判斷．

假如：查詢開始時間為Ｔ１，則在查詢獲取的資料塊中，如果資料塊的提交scn小於T1,則oracle接受該資料，如果提交的scn大於t1或者資料被鎖定修改尚未記錄commit　scn，則oracle需要通過回滾段構造前映象來返回結果．

關於ORA-01555的理解：

如果當一個查詢觸發延遲塊清除的時候，ORACLE 需要去查詢回滾段獲得該事務提交的ＳＣＮ，如果事務前映象資訊已經被覆蓋，並且查詢的ＳＣＮ小於回滾段記錄中記錄的最小提交ＳＣＮ資訊，那麼oracle將無法判斷查詢的scn和事物提交scn的大小．

如果當一個查詢觸發延遲塊清除的時候，ORACLE 需要去查詢回滾段獲得該事務提交的ＳＣＮ，如果事務前映象資訊已經被覆蓋，並且查詢的ＳＣＮ大於回滾段記錄中記錄的最小提交ＳＣＮ資訊，則將commit 標記為 回滾段中所能找到的最小 scn（對於查詢安全）．

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8334342/viewspace-417477/，如需轉載，請註明出處，否則將追究法律責任。