oracle的commit詳解
它執行的時候，你不會有什麼感覺。commit在資料庫程式設計的時候很常用，當你執行DML操作時，資料庫並不會立刻修改表中資料，這時你需要commit，資料庫中的資料就立刻修改了，如果在沒有commit之前，就算你把整個表中資料都刪了，如果rollback的話，資料依然能夠還原。聽我這麼說，你或許感覺commit沒什麼用，其實不然。當你同時執行兩條或兩條以上的sql語句時，問題就出現了。舉一個例子，你去銀行轉賬，你轉的時候銀行的資料庫會update你銀行賬戶裡面的資料，同時對另一個人得賬戶也進行update操作。這兩個程式都必須全部正確執行，才能commit，否則rollback。如果只是完成一條，要麼你鬱悶，要麼銀行鬱悶，第一種情況是，你的賬戶的錢沒少，轉賬人得賬戶上的錢多了，銀行鬱悶了。第二種情況你的銀行賬戶的錢少了，他的卻沒多，你就好鬱悶了。Oracle好好學吧！sql不難，plsql努努力也能熬過去，等到優化那，哎！DBA不是那麼好當的。還有就是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)的時間或者說提交所用的時間都基本相同。