在Oracle數據庫中，提供了一種被稱為“事務”的控制機制。通過事物，能夠完成對數據有效安全的修改操作，使數據庫中的數據達到一個數據一致的狀態。舉個簡單的例子，現在有一個借書系統中設涉及到兩張表，一張是圖書庫存表，一張是用戶借書情況表。在用戶借書的時候，數據庫需要進行兩個操作，一是從圖書庫存表中扣掉庫存;另一個操作時在用戶借書表中加入這個借書操作。數據庫在操作時，往往是先扣減庫存，然後再在用戶借書情況表中加入借書紀錄。假設用戶在借書的時候，第一步操作成功，即已經從圖書庫存表中扣除了某書的庫存;但是，在第二步時由於發現用戶借的書已經超量或者發現用戶的卡中還有罰款不能夠借書時，借書就會不成功。若沒有事務做控制的話，很明顯圖書庫存就會不准。而在事務的管理下，當第二步不成功的話，第一步操作就會發生回滾。也就是說，事務可以把數據庫的好幾個操作步驟當作一個整體，當其中有某個操作沒有成功的話，則所有操作都會發生回滾。Oracle數據庫就是通過這種機制來保障數據的一致性問題。
但是，事務若編寫的不好的話，則不但起不到應有的作用，還會大大降低數據庫的性能。如在數據庫事務執行時間比較長，就很有可能導致鎖沖突，從而降低數據庫的並發訪問性能。所以，數據庫管理員在編寫事務時，還是需要遵守幾個指導方針。
指導方針一：在事務中盡量使得訪問的紀錄最小。
在事務中，若執行Update等記錄操作語句，數據庫為了保障數據的一致性，會對其所訪問的記錄加鎖，防止在同一時間內其他用戶對其修改。此時，若其他用戶需要訪問加鎖的記錄，則必須等待。此時就會發生鎖沖突。
所以，在事務中要盡量使得訪問的記錄量最小。如此就可以減少鎖定的行數，從而減少事務之間的沖突。這要求數據庫管理員在事務中盡量精確的定位語紀錄。如在數據庫中讀取記錄時，最好能夠使用Where語句進行定位。並且在編寫Where語句的時候，要盡量的詳細，最好能夠實現一對一，則是最好的。
如在庫存盤點的時候，事務處理語句需要從數據庫中讀取一定數量的記錄，並且為這些記錄進行加鎖。此時，若記錄讀取的過多的話，就會對其他用戶訪問表中的記錄造成麻煩。為此，數據庫管理員應該建議應用前台應用程序在開發的過程中，加入一些限制條件。如按照產品的分類來更新庫存。如此的話，就可以減少一個事務一次性讀取的記錄數量，從而把鎖的影響降低到最低。
指導方針二：保持事務盡可能的簡潔。
在事務中盡量使得訪問的紀錄最小，這是從數量的角度來考慮鎖沖突。而保持事務盡可能的簡潔，則是從時間的角度來考慮避免鎖沖突的事情。保持事務盡可能的簡潔，主要是要求數據庫管理員在編寫事務的時候，不要把事務寫的太過於龐大與復雜。否則，事務在執行的時候就會占用比較多的時間。而這直接導致的後果就是數據庫會把某些記錄、甚至一張數據表鎖住比較長的時間。這就會惡化鎖對數據庫的負面影響。
故當用戶在知道了必須要進行修改的記錄之後，就要馬上啟動事務;並且在最短時間內執行完相關的修改語句，然後立即遞交或者回滾。而且，只有在確實需要時，才打開事務語句。具體的來說，數據庫管理員在事務的簡潔性方面，可以嘗試如下方法。
一是在同一個事務中不要加入過多的修改或者刪除語句。如當用戶需要更新用戶信息表中的相關數據。例如在員工的編號前加入YG前綴並且同時根據員工入職年份計算員工工齡。這兩個更新語句若從技術上來說，放在同一個事務中並沒有什麼不妥。但是，當員工數量比較多時，若把他們合並在一起，則這個事務執行得時間會比較久。為此，最好在更新數據庫表的時候，若預計執行時間會比較長，則最好能夠把更新語句進行分割，如一列列更新等等。
二是在更新時，若一次性更新的語句比較多，最好能夠選擇合適的時候更新。更新某個數據庫中記錄，其執行所需要的時間往往跟數據庫的記錄成正比。其記錄越多，更新所需要的時間越多。為此，筆者建議，當需要更新的記錄比較多的時候，最好能夠選擇合理的時機。如有些應用程序在設計時，可以把這個更新放在後台處理。如此的話，應用程序就可以選擇數據庫比較空的時候，來更新表中的記錄。這無疑可以在很大程度上降低事務對數據庫的負面影響。
指導方針三：不要在事務處理期間要求用戶輸入。
數據庫管理員在編寫事務時，要確保在事務啟動之前，讓數據庫系統獲得事務執行所需要的所有內容。如記錄的查詢條件、所需要更新的內容等等。如果在事務執行的過程中還需要用戶的輸入，就回滾當前的事務。當用戶提供了必要的參數之後，再重新啟動這個事務。因為即使在事務執行的過程中，用戶立即響應。但是，用戶的反應速度要比電腦的響應速度慢的多。所以，當用戶在事務執行的過程中需要輸入參數的話，就會使得這個事務所占用的數據庫資源要保持很長的時間。這就有可能增加阻塞的風險。因為當用戶沒有及時輸入所需要的參數時，事務仍然會保持活動狀態，並鎖定相關的資源，直到他們響應為止。若用戶所需要輸入的參數比較多時，用戶可能會幾分鐘甚至一個小時沒有輸入。
這不是一種理論上的假設，筆者在實際工作中就碰到過這種例子。如在一個ERP系統中有訂單變更的功能。若在設計的時候，在用戶打開銷售訂單變更單就觸發變更事務的話，則因為用戶輸入訂單變更所需要的時間不能夠確定。有時候用戶這邊改一改，那邊再確認一下，可能一個小時就過去了。此時，這張銷售訂單對應的內容其他用戶就無法查看了，因為數據庫中已經被這個事務鎖住。這顯然是設計的不合理的。筆者認為，應到在用戶點擊確認按鈕時，再觸發這個變更事務。此時，用戶已經輸入了所需要更改的所有內容，在更新事務的執行過程中，不需要用戶再輸入其他的額外參數。通過這種方式，就可以把事務所占用資源的時間縮短到最低。
指導方針四：在浏覽數據時，盡量不要打開事務。
根據筆者的經驗，用戶更改數據所需要的時間，其實很少。而大部分時間則是在更改數據之前對數據的分析上。如在定位需要對哪些數據要進行更改;如在更改事務遞交好的審核;如在考慮該怎麼進行更改。這個分析工作所占據的時間往往是大頭。
故筆者提醒數據庫管理員，在所有預備的數據分析完成之前，在用戶數據浏覽的時候，不要啟動事務。也就是說，在用戶更改數據的時候，仍然不是觸發更新事務的最佳時間。只有到用戶確認無誤後，選擇“更新”按鈕，此時，才可以觸發這個事務。並且，及時遞交或者回滾這個事務。如此，在事後審核的過程中，事務就不會繼續占用資源。
除了以上這些指導方針外，還有其他的一些小細節要注意。如盡量采用級別低的事務隔離級別，數據庫管理員要切記，不是所有的事務都要求串行事務隔離級別;如事務設計的簡短一些;如在事務回退時，可根據實際情況選擇回退全部事務或者是部分事務等等。另外，要特別注意在事務中排他鎖的副作用。在修改數據時，為了保障數據的一致性，往往需要利用排它鎖保護修改過的行，以防止其他任何事務讀取這一行，並且必須把排它鎖控制到遞交或者回滾事務為止。為此，數據庫管理員在設計跟更新相關的事務時，要合理選擇時機。讓事務在保障數據安全性的同時，最大限度的降低其負面作用。
