簡單點說，在oracle的block上都有活動事務的標志的，如果一個事務commit后，由于某些block在commit之前已經寫回datafile，或者事務影響到的block數過多，則commit的時候只會清理undo segment header中的事務表信息，data block上的事務標志不會清除，在否則代

簡單點說，在oracle的block上都有活動事務的標志的，如果一個事務commit后，由于某些block在commit之前已經寫回datafile，或者事務影響到的block數過多，則commit的時候只會清理undo segment header中的事務表信息，data block上的事務標志不會清除，在否則代價過高。那么在一些讀取這些block時，需要將這些事務標志進行清除，就是延遲塊清除

塊清除即清除數據塊上與“鎖定”有關的信息。Oracle的鎖機制是一種輕量級的鎖定機制，不是通過構建鎖列表來進行數據的鎖定管理，而是直接將鎖作為數據的屬性，存儲在數據塊首部。因此，每次訪問數據時都要去看數據塊頭部的鎖，如果數據已經提交，則可能需要清理這個塊，換句話說，要將這些事務信息刪除。因此這個動作就會生成redo。

Cleanout有2種，一種是fast commit cleanout（提交清除）,另一種是delayed block cleanout（延遲清除）.

提交清楚是如何工作的？Oracle會記錄已修改的塊列表，這些列表可以有20個塊，Oracle根據需要分配多個這樣的列表，但是如果這些修改的塊加起來超過buffer_cache的10%，oracle就停止分配這樣的列表，因此當提交時就只會清理最多10%buffer_cache的數據塊，其余的部分就延遲清除，這樣也是為了提高commit的效率。

還有一種情況，就是當事務還未commit時，修改的數據塊已經寫入硬盤，當發生commit時oracle并不會把block重新讀入做cleanout，而是把cleanout留到下一次對此塊的訪問是完成。

Cleanout有2種，一種是fast commit cleanout,

另一種是delayed block cleanout.Oracle的每個事務（transaction）修改不超過10%buffer cache的數據塊時，oracle做的是fast commit cleanout。如果一個事務（transaction）修改的塊超過10% buffer cache,那么超過的塊就執行delayed block cleanout，還有一種情況，就是當事務還未commit時，修改的數據塊已經寫入硬盤，當發生commit時oracle并不會把block重新讀入做cleanout，而是把cleanout留到下一次對此塊的訪問是完成。

當我們update 數據之后，并且沒有commit，此時我們flush buffer cache，將修改的數據塊，flush 到硬盤，那么此時發生的就是delay block cleanout
正常情況下，會去修改block里的相關SCN。 但是實際上此時Oracle 并沒有回去修改這些block，因為再次調用成本太大。 Oracle只更新了undo segment header slot。 當下次再次訪問這個block時，在根據undo segment 來更新block scn 和 itl 上的scn。 如果此時對應的undo segment 已經不存在，就會出發ORA-01555,快照過舊的錯誤。
做了delayed block cleanout之后，itl 變成了SCN。 此時lck,lb標志為都被清零，scn也是從undo segment header transactiontable slot里面得到。如果undosegment header 上的slot被覆蓋了，那么會把undo segment 上的control scn拿來當作upper bound scn
當delayed block cleanout 發生時，依賴與undo segment來保證，如果undo segment 被刪除了，那么會Oracle 會使用system 表空間下的undo$ 基表來保證delayed block cleanout。
一般來說，select 是不會產生redo的。 但如果發生了delayed block cleanout，那么就會產生redo。 當然這只是一種情況，開啟審計等，也會造成select 產生redo。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com