對Oracle Commit的研究

Oracle還是比較常用的，於是我研究了一下Oracle COMMIT，在這裡拿出來和大家分享一下，希望對 大家有用。只有當SQL語句影響的所有行所在的最後一個塊被讀入DB BUFFER並且重做資訊被寫入REDO LOG BUFFER之後，使用者才可以發出COMMIT，Oracle COMMIT觸發LGRW，但並不強制立即DBWN來釋放所有 相應的DB BUFFER塊上的鎖，但在隨後的一段時間內DBWN還在寫這條語句涉及的資料區塊的情形，表頭部 的行鎖，並不是在COMMIT一發出就馬上釋放，實際上要等到相應的DBWN進程結束才會釋放。  

一個使用者請求鎖定另一個使用者已COMMIT的資源不成功的機會是存在的。Oracle COMMIT發出後會將回 滾段中的"前映像"標識為已提交.DML語句會產生一個SCN號，DBWN觸發時寫入到資料區塊的頭 部，COMMIT時也會產生一個SCN號，也會被寫入資料區塊的頭部。在資料區塊的頭部只儲存一個最新的SCN號 ，

COMMIT之後這個事務插槽可以被另外一個事務使用。如果使用者ROOLBACK，則伺服器處理序會根據資料 檔案塊和DB BUFFER中塊的頭部的事務列表和SCN以及復原段地址重構出相應的修改前的副本，並且用這 些原值來還原當前資料檔案中已修改但未提交的改變。如果有多個"前映像"，伺服器處理序會 在一個"前映像"的頭部找到"前前映像"的復原段地址，一直重構出同一事務下的 最早的一個"前映像"為止。一旦發出了COMMIT，使用者就不能ROLLBACK，這使得COMMIT後DBWN 進程還沒有全部完成的後續動作得到了保障。

下面我們要提到檢查點的作用，ckpt的觸發，有以下幾種情況：

1.當發生日誌組切換的時候

2.當滿足log_checkpoint_timeout、log_checkpoint_interval、fast_start_io_target、 fast_start_mttr_target參數設定的時候

3.當運行alter system switchlogfile的時候

4.當運行alter systemckeckpoint的時候

5.當運行altertablespacetbs_namebegin backup[end backup]的時候

6.當運行altertablespace[datafile] offline的時候

7.系統正常關閉時

只有在4.7兩種情況下發生完全檢查點。發生完全檢查點時，首先系統記錄檢查點對應的Checkpoint SCN，並記錄下該時刻修改的DB BUFFER對應的記錄檔的最新的重做位元組地址（Redo Byte Address (RBA)），然後DBWN進程將這個重做位元組地址（RBA）之前已發生的DB BUFFER中的髒緩衝寫入資料檔案 （之所以要以重做位元組地址（RBA）為標誌是因為在檢查點發生到檢查點完成之間的時間內，系統還在 一直不斷的產生修改，這些修改所產生的DB BUFFER髒緩衝，以及日誌條目將不會影響這次檢查點最後 確認的一致性結果，也就是最後確認這個Checkpoint SCN之前的系統是一致的）。

最後把Checkpoint SCN和RBA更新至控制檔案，Checkpoint SCN更新至每個資料檔案頭部，表明當前 資料庫是一致的。日誌切換並不導致一個完全檢點的發生，比如有三個記錄檔組,當發生日誌切換時 發生檢查點,而發生日誌切換一般是因為當前的LGWR正在寫重做日誌,也就是LGWR當剛寫滿2號日誌就立 即觸發檢查點,於是系統開始核對3號日誌中記錄的REDO項目所對應的資料是否已經從DB BUFFER中寫入 資料檔案(不管事務是否已提交),如果沒有寫入,檢查點就觸發DBWN進程將這些緩衝塊寫入資料檔案,顯 然LGWR因此而發生等待,除此以外,檢查點還讓DBWN進程將在2號日誌中對應修改的DB BUFFER塊寫入資料 檔案,然後繼續LGWR進程,直到LGWR進程將LGWR觸發之前存在於REDO LOG BUFFER中的所有緩衝（包含未 提交的重做資訊）寫入重做記錄檔,檢查點再更新資料檔案,控制檔案頭部SCN。其實LGWR等待的並不 是CKPT的完成，而是等待CKPT觸發的DBWN進程的完成。