oracle 資料庫悲觀鎖和樂觀鎖

Oracle資料庫悲觀鎖與樂觀鎖詳解

本文标簽：Oracle　悲觀鎖　樂觀鎖　 　　Oracle資料庫悲觀鎖與樂觀鎖是本文我們主要要介紹的内容  。有時候為了得到最大的性能，一般資料庫都有并發機制，不過帶來的問題就是資料通路的沖突  。為了解決這個問題，大多數資料庫用的方法就是資料的鎖定  。 　　資料的鎖定分為兩種方法，第一種叫做悲觀鎖，第二種叫做樂觀鎖  。什麼叫悲觀鎖呢，悲觀鎖顧名思義，就是對資料的沖突采取一種悲觀的态度，也就是說假設資料肯定會沖突，是以在資料開始讀取的時候就把資料鎖定住  。而樂觀鎖就是認為資料一般情況下不會造成沖突，是以在資料進行送出更新的時候，才會正式對資料的沖突與否進行檢測，如果發現沖突了，則讓使用者傳回錯誤的資訊，讓使用者決定如何去做  。 　　先從悲觀鎖開始說  。在SqlServer等其餘很多資料庫中，資料的鎖定通常采用頁級鎖的方式，也就是說對一張表内的資料是一種串行化的更新插入機制，在任何時間同一張表隻會插1條資料，别的想插入的資料要等到這一條資料插完以後才能依次插入 （此句有待考證，我覺得其他的資料庫應該也會直接不同的鎖定方式） 。帶來的後果就是性能的降低，在多使用者并發通路的時候，當對一張表進行頻繁操作時，會發現響應效率很低，資料庫經常處于一種假死狀态  。而Oracle用的是行級鎖，隻是對想鎖定的資料才進行鎖定，其餘的資料不相幹，是以在對Oracle表中并發插資料的時候，基本上不會有任何影響  。 　　注：對于悲觀鎖是針對并發的可能性比較大，而一般在我們的應用中用樂觀鎖足以  。 　　Oracle的悲觀鎖需要利用一條現有的連接配接，分成兩種方式，從SQL語句的差別來看，就是一種是for update，一種是for update nowait的形式  。比如我們看一個例子  。首先建立測試用的資料庫表  。 　　CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept 　　這裡我們利用了Oracle的Sample的scott使用者的表，把資料copy到我們的test表中  。首先我們看一下for update鎖定方式  。首先我們執行如下的select for update語句  。 　　select * from test where id = 10 for update 　　通過這條檢索語句鎖定以後，再開另外一個sql*plus視窗進行操作，再把上面這條sql語句執行一便，你會發現sqlplus好像死在那裡了，好像檢索不到資料的樣子，但是也不傳回任何結果，就屬于卡在那裡的感覺  。這個時候是什麼原因呢，就是一開始的第一個Session中的select for update語句把資料鎖定住了  。由于這裡鎖定的機制是wait的狀态(隻要不表示nowait那就是wait)，是以第二個Session(也就是卡住的那個sql*plus)中目前這個檢索就處于等待狀态  。當第一個session最後commit或者rollback之後，第二個session中的檢索結果就是自動跳出來，并且也把資料鎖定住  。不過如果你第二個session中你的檢索語句如下所示  。 　　select * from test where id = 10 　　也就是沒有for update這種鎖定資料的語句的話，就不會造成阻塞了  。另外一種情況，就是當資料庫資料被鎖定的時候，也就是執行剛才for update那條sql以後，我們在另外一個session中執行for update nowait後又是什麼樣呢  。比如如下的sql語句  。 由于這條語句中是制定采用nowait方式來進行檢索，是以當發現資料被别的session鎖定中的時候，就會迅速傳回ORA-00054錯誤，内容是資源正忙, 但指定以 NOWAIT 方式擷取資源  。是以在程式中我們可以采用nowait方式迅速判斷目前資料是否被鎖定中，如果鎖定中的話，就要采取相應的業務措施進行處理  。 　　select * from test where id = 10 for update nowait 　　那這裡另外一個問題，就是當我們鎖定住資料的時候，我們對資料進行更新和删除的話會是什麼樣呢  。比如同樣，我們讓第一個Session鎖定住id=10的那條資料，我們在第二個session中執行如下語句  。 　　update test set value=2 where id = 10 　　這個時候我們發現update語句就好像select for update語句一樣也停住卡在這裡，當你第一個session放開鎖定以後update才能正常運作  。當你update運作後，資料又被你update語句鎖定住了，這個時候隻要你update後還沒有commit，别的session照樣不能對資料進行鎖定更新等等  。 　　總之，Oracle中的悲觀鎖就是利用Oracle的Connection對資料進行鎖定  。在Oracle中，用這種行級鎖帶來的性能損失是很小的，隻是要注意程式邏輯，不要給你一不小心搞成死鎖了就好  。而且由于資料的及時鎖定，在資料送出時候就不呼出現沖突，可以省去很多惱人的資料沖突處理  。缺點就是你必須要始終有一條資料庫連接配接，就是說在整個鎖定到最後放開鎖的過程中，你的資料庫聯接要始終保持住  。與悲觀鎖相對的，我們有了樂觀鎖  。樂觀鎖一開始也說了，就是一開始假設不會造成資料沖突，在最後送出的時候再進行資料沖突檢測  。 　　在樂觀鎖中，我們有3種常用的做法來實作： 　　[1]第一種就是在資料取得的時候把整個資料都copy到應用中，在進行送出的時候比對目前資料庫中的資料和開始的時候更新前取得的資料  。當發現兩個資料一模一樣以後，就表示沒有沖突可以送出，否則則是并發沖突，需要去用業務邏輯進行解決  。 　　[2]第二種樂觀鎖的做法就是采用版本戳，這個在Hibernate中得到了使用  。采用版本戳的話，首先需要在你有樂觀鎖的資料庫table上建立一個新的column，比如為number型，當你資料每更新一次的時候，版本數就會往上增加1  。比如同樣有2個session同樣對某條資料進行操作  。兩者都取到目前的資料的版本号為1，當第一個session進行資料更新後，在送出的時候檢視到目前資料的版本還為1，和自己一開始取到的版本相同  。就正式送出，然後把版本号增加1，這個時候目前資料的版本為2  。 　　當第二個session也更新了資料送出的時候，發現資料庫中版本為2，和一開始這個session取到的版本号不一緻，就知道别人更新過此條資料，這個時候再進行業務處理，比如整個Transaction都Rollback等等操作  。在用版本戳的時候，可以在應用程式側使用版本戳的驗證，也可以在資料庫側采用Trigger(觸發器)來進行驗證  。不過資料庫的Trigger的性能開銷還是比較的大，是以能在應用側進行驗證的話還是推薦不用Trigger  。 　　[3]第三種做法和第二種做法有點類似，就是也新增一個Table的Column，不過這次這個column是采用timestamp型，存儲資料最後更新的時間  。在Oracle9i以後可以采用新的資料類型，也就是timestampwith time zone類型來做時間戳  。這種Timestamp的資料精度在Oracle的時間類型中是最高的，精确到微秒(還沒與到納秒的級别)，一般來說，加上資料庫處理時間和人的思考動作時間，微秒級别是非常非常夠了，其實隻要精确到毫秒甚至秒都應該沒有什麼問題  。和剛才的版本戳類似，也是在更新送出的時候檢查目前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一緻則OK，否則就是版本沖突  。如果不想把代碼寫在程式中或者由于别的原因無法把代碼寫在現有的程式中，也可以把這個時間戳樂觀鎖邏輯寫在Trigger或者存儲過程中  。