oracle的commit詳解

語言: CN / TW / HK

場景:commit執行的時候,你不會有什麼感覺。commit在資料庫程式設計的時候很常用,當你執行DML操作時,資料庫並不會立刻修改表中資料,這時你需要commit,資料庫中的資料就立刻修改了,如果在沒有commit之前,就算你把整個表中資料都刪了,如果rollback的話,資料依然能夠還原。聽我這麼說,你或許感覺commit沒什麼用,其實不然。當你同時執行兩條或兩條以上的sql語句時,問題就出現了。舉一個例子,你去銀行轉賬,你轉的時候銀行的資料庫會update你銀行賬戶裡面的資料,同時對另一個人得賬戶也進行update操作。這兩個程式都必須全部正確執行,才能commit,否則rollback。如果只是完成一條,要麼你鬱悶,要麼銀行鬱悶,第一種情況是,你的賬戶的錢沒少,轉賬人得賬戶上的錢多了,銀行鬱悶了。第二種情況你的銀行賬戶的錢少了,他的卻沒多,你就好鬱悶了。還有就是commit算是顯式提交,還有隱式提交,並不是,不commit的話,你的全部努力就都白費了。

 

這個命令是將資料寫到資料庫中。

如果不執行COMMIT這個命令,那麼在你這個session之外的其他session查詢的資料是你修改資料之前的資料。

而COMMIT之後人家查詢的是你修改的資料。你可以開啟兩個sqlplus比較做一下測試。一目瞭然。
commit的提交針對的是:DML
Data Manipulation Language(DML) 需要提交,這部分是對資料管理操作,比如Insert(插入)、Update(修改)、Delete(刪除),
Data Definition Language(DDL) 不需要提交,這部分是對資料結構定義,比如 Create(建立)、Alter(修改)、Drop(刪除)

oracle的commit就是提交資料(這裡是釋放鎖不是鎖表),在未提交前你前面的操作更新的都是記憶體,沒有更新到物理檔案中。執行commit從使用者角度講就是更新到物理檔案了,事實上commit時還沒有寫date file,而是記錄了redo log file,要從記憶體寫到data物理檔案,需要觸發檢查點,由DBWR這個後臺程序來寫,這裡內容有點多的,如果不深究的話你就理解成commit即為從記憶體更新到物理檔案。鎖有很多種,一般我們關注的都是DML操作產生的,比如insert,delete,update,select...for update都會同時觸發表級鎖和行級鎖

補充:insert以後commit之前是鎖表的狀態,其他事務無法對該表進行操作。
如果不提交的話,那麼這個表就被鎖了

 

COMMIT通常是一個非常快的操作,而不論事務大小如何。你可能認為,一個事務越大(換句話說,它影響的資料越多),COMMIT需要的時間就越長。不是這樣的。不論事務有多大,COMMIT的響應時間一般都很“平”(flat,可以理解為無高低變化)。這是因為COMMIT並沒有太多的工作去做,不過它所做的確實至關重要。
  這一點很重要,之所以要了解並掌握這個事實,原因之一是:這樣你就能心無芥蒂地讓事務有足夠的大小。一種錯誤的信念認為分批提交可以節省稀有的系統資源,而實際上這只是增加了資源的使用。如果只在必要時才提交(即邏輯工作單元結束時),不僅能提高效能,還能減少對共享資源的競爭(日誌檔案、各種內部閂等)。

 

分批提交COMMIT的開銷存在兩個因素:

  顯然會增加與資料庫的往返通訊。如果每個記錄都提交,生成的往返通訊量就會大得多。

  每次提交時,必須等待redo寫至磁碟。這會導致“等待”。在這種情況下,等待稱為“日誌檔案同步”(log file sync)。

  為什麼COMMIT的響應時間相當“平”,而不論事務大小呢?在資料庫中執行COMMIT之前,困難的工作都已經做了。我們已經修改了資料庫中的資料,所以99.9%的工作都已經完成。例如,已經發生了以下操作:

  已經在SGA中生成了undo塊。

  已經在SGA中生成了已修改資料塊。

  已經在SGA中生成了對於前兩項的快取redo。

  取決於前三項的大小,以及這些工作花費的時間,前面的每個資料(或某些資料)可能已經重新整理輸出到磁碟。

  已經得到了所需的全部鎖。

  執行COMMIT時,餘下的工作只是:

  為事務生成一個SCN。如果你還不熟悉SCN,起碼要知道,SCN是Oracle使用的一種簡單的計時機制,用於保證事務的順序,並支援失敗恢復。SCN 還用於保證資料庫中的讀一致性和檢查點。可以把SCN看作一個鐘擺,每次有人COMMIT時,SCN都會增1.

  LGWR將所有餘下的快取重做日誌條目寫到磁碟,並把SCN記錄到線上重做日誌檔案中。這一步就是真正的COMMIT。如果出現了這一步,即已經提交。事務條目會從V$TRANSACTION中“刪除”,這說明我們已經提交。

  V$LOCK中記錄這我們的會話持有的鎖,這些所都將被釋放,而排隊等待這些鎖的每一個人都會被喚醒,可以繼續完成他們的工作。

  如果事務修改的某些塊還在緩衝區快取中,則會以一種快速的模式訪問並“清理”。塊清除(Block cleanout)是指清除儲存在資料庫塊首部的與鎖相關的資訊。實質上講,我們在清除塊上的事務資訊,這樣下一個訪問這個塊的人就不用再這麼做了。我們採用一種無需生成重做日誌資訊的方式來完成塊清除,這樣可以省去以後的大量工作(在下面的“塊清除”一節中將更全面地討論這個問題)。

  可以看到,處理COMMIT所要做的工作很少。其中耗時最長的操作要算LGWR執行的活動(一般是這樣),因為這些磁碟寫是物理磁碟I/O。不過,這裡LGWR花費的時間並不會太多,之所以能大幅減少這個操作的時間,原因是LGWR一直在以連續的方式重新整理輸出重做日誌緩衝區的內容。在你工作期間,LGWR並非快取這你做的所有工作;實際上,隨著你的工作的進行,LGWR會在後臺增量式地重新整理輸出重做日誌緩衝區的內容。這樣做是為了避免COMMIT等待很長時間來一次性重新整理輸出所有的redo。

  因此,即使我們有一個長時間執行的事務,但在提交之前,它生成的許多快取重做日誌已經重新整理輸出到磁碟了(而不是全部等到提交時才重新整理輸出)。這也有不好的一面,COMMIT時,我們必須等待,直到尚未寫出的所有快取redo都已經安全寫到磁碟上才行。也就是說,對LGWR的呼叫是一個同步(synchronous)呼叫。儘管LGWR本身可以使用非同步I/O並行地寫至日誌檔案,但是我們的事務會一直等待LGWR完成所有寫操作,並收到資料都已在磁碟上的確認才會返回。

  前面我提高過,由於某種原因,我們用的是一個Java程式而不是PL/SQL,這個原因就是 PL/SQL提供了提交時優化(commit-time optimization)。我說過,LGWR是一個同步呼叫,我們要等待它完成所有寫操作。在Oracle 10g Release 1及以前版本中,除PL/SQL以外的所有程式語言都是如此。PL/SQL引擎不同,要認識到直到PL/SQL例程完成之前,客戶並不知道這個PL /SQL例程中是否發生了COMMIT,所以PL/SQL引擎完成的是非同步提交。它不會等待LGWR完成;相反,PL/SQL引擎會從COMMIT呼叫立即返回。不過,等到PL/SQL例程完成,我們從資料庫返回客戶時,PL/SQL例程則要等待LGWR完成所有尚未完成的COMMIT。因此,如果在PL /SQL中提交了100次,然後返回客戶,會發現由於存在這種優化,你只會等待LGWR一次,而不是100次。這是不是說可以在PL/SQL中頻繁地提交呢?這是一個很好或者不錯的主意嗎?不是,絕對不是,在PL/SQ;中頻繁地提交與在其他語言中這樣做同樣糟糕。指導原則是,應該在邏輯工作單元完成時才提交,而不要在此之前草率地提交。

  COMMIT是一個“響應時間很平”的操作,雖然不同的操作將生成不同大小的redo,即使大小相差很大或者說無論生成多少redo,但也並不會影響提交(COMMIT)的時間或者說提交所用的時間都基本相同。

​​​​​​​