樂觀鎖一開始也說了,就是一開始假設(shè)不會造成數(shù)據(jù)沖突,在最后提交的時候再進行數(shù)據(jù)沖突檢測。在樂觀鎖中,我們有3種
成都創(chuàng)新互聯(lián)從2013年開始,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項目做網(wǎng)站、成都做網(wǎng)站網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元洛隆做網(wǎng)站,已為上家服務(wù),為洛隆各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575
常用的做法來實現(xiàn)。
[1]第一種就是在數(shù)據(jù)取得的時候把整個數(shù)據(jù)都copy到應(yīng)用中,在進行提交的時候比對當(dāng)前數(shù)據(jù)庫中的數(shù)據(jù)和開始的時候更新前取得的數(shù)據(jù)。當(dāng)發(fā)現(xiàn)兩個數(shù)據(jù)一模一樣以后,就表示沒有沖突可以提交,否則則是并發(fā)沖突,需要去用業(yè)務(wù)邏輯進行解決。
[2]第二種樂觀鎖的做法就是采用版本戳,這個在Hibernate中得到了使用。采用版本戳的話,首先需要在你有樂觀鎖的數(shù)據(jù)庫table上建立一個新的column,比如為number型,當(dāng)你數(shù)據(jù)每更新一次的時候,版本數(shù)就會往上增加1。比如同樣有2個session同樣對某條數(shù)據(jù)進行操作。兩者都取到當(dāng)前的數(shù)據(jù)的版本號為1,當(dāng)?shù)谝粋€session進行數(shù)據(jù)更新后,在提交的時候查看到當(dāng)前數(shù)據(jù)的版本還為1,和自己一開始取到的版本相同。就正式提交,然后把版本號增加1,這個時候當(dāng)前數(shù)據(jù)的版本為2。當(dāng)?shù)诙€session也更新了數(shù)據(jù)提交的時候,發(fā)現(xiàn)數(shù)據(jù)庫中版本為2,和一開始這個session取到的版本號不一致,就知道別人更新過此條數(shù)據(jù),這個
時候再進行業(yè)務(wù)處理,比如整個Transaction都Rollback等等操作。在用版本戳的時候,可以在應(yīng)用程序側(cè)使用版本戳的驗證,也可以在數(shù)據(jù)庫側(cè)采用Trigger(觸發(fā)器)來進行驗證。不過數(shù)據(jù)庫的Trigger的性能開銷還是比較的大,所以能在應(yīng)用側(cè)進行驗證的話還是推薦不用Trigger。
[3]第三種做法和第二種做法有點類似,就是也新增一個Table的Column,不過這次這個column是采用timestamp型,存儲數(shù)據(jù)最后更新的時間。在Oracle9i以后可以采用新的數(shù)據(jù)類型,也就是timestamp with time zone類型來做時間戳。這種Timestamp的數(shù)據(jù)精度在Oracle的時間類型中是最高的,精確到微秒(還沒與到納秒的級別),一般來說,加上數(shù)據(jù)庫處理時間和人的思考動作時間,微秒級別是非常非常夠了,其實只要精確到毫秒甚至秒都應(yīng)該沒有什么問題。和剛才的版本戳類似,也是在更新提交的時候檢查當(dāng)前數(shù)據(jù)庫中數(shù)據(jù)的時間戳和自己更新前取到的時間戳進行對比,如果一致則OK,否則就是版本沖突。如果不想把代碼寫在程序中或者由于別的原因無法把代碼寫在現(xiàn)有的程序中,也可以把這個時間戳樂觀鎖邏輯寫在Trigger或者存儲過程中。
數(shù)據(jù)庫事務(wù)及隔離級別
隔離級別:臟讀、幻讀、一致讀、不可重復(fù)讀、更新丟失
1.臟讀(Dirty Reads):一個事務(wù)開始讀取了某行數(shù)據(jù)但是另外一個事務(wù)已經(jīng)更新了此數(shù)據(jù)但沒有能夠及時提交。這是相當(dāng)危險很可能所有操作都被回滾
2.幻讀(Phantom Reads):也稱為幻像(幻影)。事務(wù)在操作過程中進行兩次查詢,第二次查詢結(jié)果包含了第一次查詢中未出現(xiàn)的數(shù)據(jù)(這里并不要求兩次查詢SQL語句相同)這是因為在兩次查詢過程中有另外一個事務(wù)插入數(shù)據(jù)造成的
3.不可重復(fù)讀(Non-repeatable Reads):一個事務(wù)對同一行數(shù)據(jù)重復(fù)讀取兩次但是卻得到了不同結(jié)果。例如在兩次讀取中途有另外一個事務(wù)對該行數(shù)據(jù)進行了修改并提交
4.兩次更新問題(Second lost updates problem):無法重復(fù)讀取特例,有兩個并發(fā)事務(wù)同時讀取同一行數(shù)據(jù)然后其中一個對它進行修改提交而另一個也進行了修改提交這就會造成第一次寫操作失效
5.更新丟失(Lost update):兩個事務(wù)都同時更新一行數(shù)據(jù)但是第二個事務(wù)卻中途失敗退出導(dǎo)致對數(shù)據(jù)兩個修改都失效了這是系統(tǒng)沒有執(zhí)行任何鎖操作因此并發(fā)事務(wù)并沒有被隔離開
20、鎖是什么?
鎖:在所有的DBMS(數(shù)據(jù)庫管理系統(tǒng))中,鎖是實現(xiàn)事務(wù)的關(guān)鍵,鎖可以保證事務(wù)的完整性和并發(fā)性。與現(xiàn)實生活中鎖一樣,它可以使某些數(shù)據(jù)的擁有者,在某段時間內(nèi)不能使用某些數(shù)據(jù)或數(shù)據(jù)結(jié)構(gòu)。當(dāng)然鎖還分級別的。
鎖分為行級鎖和表鎖。
行級鎖:主要是在執(zhí)行操作過程中,鎖定指定的行。
主要的鎖行語句有:insert ,update,delete ,及select ....for update。
表鎖:指在運行操作指令過程中,由用戶指定鎖定某張表。lock table XXX in mode share;
共享鎖,排他鎖,共享排它,行共享,行排他。
鎖模式包括?
共享鎖:(讀?。┎僮鲃?chuàng)建的鎖。其他用戶可以并發(fā)讀取數(shù)據(jù),但任何事物都不能獲取數(shù)據(jù)上的排它鎖,直到已釋放所有共享鎖。
排他鎖(X鎖):對數(shù)據(jù)A加上排他鎖后,則其他事務(wù)不能再對A加任任何類型的封鎖。獲準(zhǔn)排他鎖的事務(wù)既能讀數(shù)據(jù),又能修改數(shù)據(jù)。
更新鎖:更新 (U) 鎖可以防止通常形式的死鎖。如果兩個事務(wù)獲得了資源上的共享模式鎖,然后試圖同時更新數(shù)據(jù),則兩個事務(wù)需都要轉(zhuǎn)換共享鎖為排它 (X) 鎖,并且每個事務(wù)都等待另一個事務(wù)釋放共享模式鎖,因此發(fā)生死鎖。
若要避免這種潛 在的死鎖問題,請使用更新 (U) 鎖。一次只有一個事務(wù)可以獲得資源的更新 (U) 鎖。如果事務(wù)修改資源,則更新 (U) 鎖轉(zhuǎn)換為排它 (X) 鎖。否則,鎖轉(zhuǎn)換為共享鎖。
鎖的粒度主要有以下幾種類型:
行鎖: 粒度最小,并發(fā)性最高
頁鎖:一次鎖定一頁。25個行鎖可升級為一個頁鎖。
表鎖:粒度大,并發(fā)性低
數(shù)據(jù)庫鎖:控制整個數(shù)據(jù)庫操作
樂觀鎖:樂觀鎖假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會造成沖突,所以在數(shù)據(jù)進行提交更新的時候,才會正式對數(shù)據(jù)的沖突與否進行檢測,如果發(fā)現(xiàn)沖突了,則讓返回用戶錯誤的信息,讓用戶決定如何去做。一般的實現(xiàn)樂觀鎖的方式就是記錄數(shù)據(jù)版本。
悲觀鎖:每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改,所以每次在拿數(shù)據(jù)的時候都會上鎖,這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機制,比如行鎖,表鎖,讀鎖,寫鎖等,都是在做操作之前先上鎖。
20、數(shù)據(jù)庫的樂觀鎖和悲觀鎖是什么? oracle 是行級鎖
數(shù)據(jù)庫管理系統(tǒng)(DBMS)中,并發(fā)控制的任務(wù)是:確保在多個事務(wù)同時存取同一數(shù)據(jù)時,不破壞事務(wù)的隔離性和統(tǒng)一性以及數(shù)據(jù)庫的統(tǒng)一性。
悲觀鎖:假定會發(fā)生并發(fā)沖突,屏蔽一切可能違反數(shù)據(jù)完整性的操作
樂觀鎖:假設(shè)不會發(fā)生并發(fā)沖突,只在提交操作時檢查是否違反數(shù)據(jù)完整性。
21、悲觀鎖和樂觀鎖的區(qū)別,怎么實現(xiàn)
悲觀鎖:一段執(zhí)行邏輯加上悲觀鎖,不同線程同時執(zhí)行時,只能有一個線程執(zhí)行,其他的線程在入口處等待,直到鎖被釋放。
樂觀鎖:一段執(zhí)行邏輯加上樂觀鎖,不同線程同時執(zhí)行時,可以同時進入執(zhí)行,在最后更新數(shù)據(jù)的時候要檢查這些數(shù)據(jù)是否被其他線程修改了(版本和執(zhí)行初是否相同),沒有修改則進行更新,否則放棄本次操作。
Oracle數(shù)據(jù)庫的鎖類型
根據(jù)保護的對象不同,Oracle數(shù)據(jù)庫鎖可以分為以下幾大類:DML鎖(data locks,數(shù)據(jù)鎖),用于保護數(shù)據(jù)的完整性;DDL鎖(dictionary locks,字典鎖),用于保護數(shù)據(jù)庫對象的結(jié)構(gòu),如表、索引等的結(jié)構(gòu)定義;內(nèi)部鎖和閂(internal locks and latches),保護數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)。
DML鎖的目的在于保證并發(fā)情況下的數(shù)據(jù)完整性,本文主要討論DML鎖。在Oracle數(shù)據(jù)庫中,DML鎖主要包括TM鎖和TX鎖,其中TM鎖稱為表級鎖,TX鎖稱為事務(wù)鎖或行級鎖。
當(dāng)Oracle執(zhí)行DML語句時,系統(tǒng)自動在所要操作的表上申請TM類型的鎖。當(dāng)TM鎖獲得后,系統(tǒng)再自動申請TX類型的鎖,并將實際鎖定的數(shù)據(jù)行的鎖標(biāo)志位進行置位。這樣在事務(wù)加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標(biāo)志,而只需檢查TM鎖模式的相容性即可,大大提高了系統(tǒng)的效率。TM鎖包括了SS、SX、S、X等多種模式,在數(shù)據(jù)庫中用0-6來表示。不同的SQL操作產(chǎn)生不同類型的TM鎖。如表1所示。
在數(shù)據(jù)行上只有X鎖(排他鎖)。在 Oracle數(shù)據(jù)庫中,當(dāng)一個事務(wù)首次發(fā)起一個DML語句時就獲得一個TX鎖,該鎖保持到事務(wù)被提交或回滾。當(dāng)兩個或多個會話在表的同一條記錄上執(zhí)行DML語句時,第一個會話在該條記錄上加鎖,其他的會話處于等待狀態(tài)。當(dāng)?shù)谝粋€會話提交后,TX鎖被釋放,其他會話才可以加鎖。
當(dāng)Oracle數(shù)據(jù)庫發(fā)生TX鎖等待時,如果不及時處理常常會引起Oracle數(shù)據(jù)庫掛起,或?qū)е滤梨i的發(fā)生,產(chǎn)生ORA-60的錯誤。這些現(xiàn)象都會對實際應(yīng)用產(chǎn)生極大的危害,如長時間未響應(yīng),大量事務(wù)失敗等。
TX鎖等待的分析
在介紹了有關(guān)地Oracle數(shù)據(jù)庫鎖的種類后,下面討論如何有效地監(jiān)控和解決鎖等待現(xiàn)象,及在產(chǎn)生死鎖時如何定位死鎖的原因。
監(jiān)控鎖的相關(guān)視圖 數(shù)據(jù)字典是Oracle數(shù)據(jù)庫的重要組成部分,用戶可以通過查詢數(shù)據(jù)字典視圖來獲得數(shù)據(jù)庫的信息。和鎖相關(guān)的數(shù)據(jù)字典視圖如表2所示。
TX鎖等待的監(jiān)控和解決在日常工作中,如果發(fā)現(xiàn)在執(zhí)行某條SQL時數(shù)據(jù)庫長時間沒有響應(yīng),很可能是產(chǎn)生了TX鎖等待的現(xiàn)象。為解決這個問題,首先應(yīng)該找出持鎖的事務(wù),然后再進行相關(guān)的處理,如提交事務(wù)或強行中斷事務(wù)。
死鎖的監(jiān)控和解決在數(shù)據(jù)庫中,當(dāng)兩個或多個會話請求同一個資源時會產(chǎn)生死鎖的現(xiàn)象。死鎖的常見類型是行級鎖死鎖和頁級鎖死鎖,Oracle數(shù)據(jù)庫中一般使用行級鎖。下面主要討論行級鎖的死鎖現(xiàn)象。
當(dāng)Oracle檢測到死鎖產(chǎn)生時,中斷并回滾死鎖相關(guān)語句的執(zhí)行,報ORA-00060的錯誤并記錄在數(shù)據(jù)庫的日志文件alertSID.log中。同時在user_dump_dest下產(chǎn)生了一個跟蹤文件,詳細描述死鎖的相關(guān)信息。
在日常工作中,如果發(fā)現(xiàn)在日志文件中記錄了ora-00060的錯誤信息,則表明產(chǎn)生了死鎖。這時需要找到對應(yīng)的跟蹤文件,根據(jù)跟蹤文件的信息定位產(chǎn)生的原因。
如果查詢結(jié)果表明,死鎖是由于bitmap索引引起的,將IND_T_PRODUCT_HIS_STATE索引改為normal索引后,即可解決死鎖的問題。
表1 Oracle的TM鎖類型
鎖模式 鎖描述 解釋 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行級共享鎖,其他對象只能查詢這些數(shù)據(jù)行 Select for update、Lock for update、Lock row share
3 SX(Row-X) 行級排它鎖,在提交前不允許做DML操作 Insert、Update、Delete、Lock row share
4 S(Share) 共享鎖 Create index、Lock share
5 SSX(S/Row-X) 共享行級排它鎖 Lock share row exclusive
6 X(Exclusive) 排它鎖 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
表2 數(shù)據(jù)字典視圖說明
視圖名 描述 主要字段說明
v$session 查詢會話的信息和鎖的信息。 sid,serial#:表示會話信息。
program:表示會話的應(yīng)用程序信息。
row_wait_obj#:表示等待的對象。
和dba_objects中的object_id相對應(yīng)。
v$session_wait 查詢等待的會話信息。 sid:表示持有鎖的會話信息。
Seconds_in_wait:表示等待持續(xù)的時間信息
Event:表示會話等待的事件。
v$lock 列出系統(tǒng)中的所有的鎖。 Sid:表示持有鎖的會話信息。
Type:表示鎖的類型。值包括TM和TX等。
ID1:表示鎖的對象標(biāo)識。
lmode,request:表示會話等待的鎖模式的信
息。用數(shù)字0-6表示,和表1相對應(yīng)。
dba_locks 對v$lock的格式化視圖。 Session_id:和v$lock中的Sid對應(yīng)。
Lock_type:和v$lock中的type對應(yīng)。
Lock_ID1: 和v$lock中的ID1對應(yīng)。
Mode_held,mode_requested:和v$lock中
的lmode,request相對應(yīng)。
v$locked_object 只包含DML的鎖信息,包括回滾段和會話信息。 Xidusn,xidslot,xidsqn:表示回滾段信息。和
v$transaction相關(guān)聯(lián)。
Object_id:表示被鎖對象標(biāo)識。
Session_id:表示持有鎖的會話信息。
Locked_mode:表示會話等待的鎖模式的信
息,和v$lock中的lmode一致。
col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有長期出現(xiàn)的一列,可能是沒有釋放的鎖。我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖:
alter system kill session 'sid,serial# ';
如果出現(xiàn)了鎖的問題, 某個DML操作可能等待很久沒有反應(yīng)。
當(dāng)你采用的是直接連接數(shù)據(jù)庫的方式,也不要用OS系統(tǒng)命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接,因為一個用戶進程可能產(chǎn)生一個以上的鎖, 殺OS進程并不能徹底清除鎖的問題
Oracle鎖表(死鎖) 2011-05-03 17:46:41| 分類: Java技術(shù) | 標(biāo)簽: |字號大中小 訂閱 .
數(shù)據(jù)庫與操作系統(tǒng)一樣,是一個多用戶使用的共享資源。 當(dāng)多個用戶并發(fā)地存取數(shù)據(jù)時,在數(shù)據(jù)庫中就會發(fā)生多個事務(wù)同時存取同一數(shù)據(jù)地情況。 若對并發(fā)操作不加控制就可能會讀取和存儲不正確地數(shù)據(jù),破壞數(shù)據(jù)庫地一致性。 加鎖時實現(xiàn)數(shù)據(jù)庫并發(fā)控制地一個非常重要地技術(shù)。 在實際應(yīng)用中經(jīng)常會遇到地與鎖相關(guān)地異常情況,當(dāng)兩個事務(wù)需要一組有沖突的鎖,而不能將事務(wù)繼續(xù)下去的話,就會出現(xiàn)死鎖,嚴(yán)重影響應(yīng)用的正常執(zhí)行。
在數(shù)據(jù)庫中有兩種基本的鎖類型:排它鎖(Exclusive Locks,即X鎖)和共享鎖(即S鎖)。當(dāng)數(shù)據(jù)對象被加上排它鎖時,其他的事務(wù)不能不能對它讀取和修改。加了共享鎖的數(shù)據(jù)對象可以被其他事務(wù)讀取,但不能修改。數(shù)據(jù)庫利用這兩種基本的鎖類型來對數(shù)據(jù)庫的事務(wù)進行并發(fā)控制。
死鎖的第一種情況:
一個用戶A訪問表A(鎖住了表A),然后又訪問表B; 另一個用戶B訪問表B(鎖住了表B),然后企圖訪問表A;這時用戶A由于用戶B已經(jīng)鎖住表B,它必須等待用戶B釋放表B才能繼續(xù),同樣用戶B要等用戶A釋放表A才能繼續(xù),這就死鎖產(chǎn)生了。
解決方法:
這種死鎖比較常見,是由于程序的BUG產(chǎn)生的,除了調(diào)整程序的邏輯沒有其它的辦法。仔細分析程序的邏輯,對于數(shù)據(jù)庫的多表操作時,盡量按照同樣的順序進行處理,盡量避免同時鎖定兩個資源,如操作A和B兩張表時,總是按先A后B的順序處理,必須同時鎖定兩個資源時,要保證在任何時刻都應(yīng)該按照相同的順序來鎖定資源。
死鎖的第二種情況
用戶A查詢一條記錄,然后修改該條記錄;這時用戶B修改該條記錄,這時用戶A的事務(wù)里鎖的性質(zhì)由查詢的共享鎖企圖上升到獨占鎖,而用戶B里的獨占鎖由于A有共享鎖存在必須等A釋放掉共享鎖,而A由于B的獨占鎖而無法上升到獨占鎖也就不可能釋放共享鎖,于是出現(xiàn)了死鎖。這種死鎖比較隱蔽,但在稍大點的項目種經(jīng)常發(fā)生,如在某項目中,頁面上的按鈕點擊后,沒有使按鈕立刻失效,使得用戶會多次快速點擊同一按鈕,這樣同一段代碼對數(shù)據(jù)庫同一條記錄進行多次操作,很容易就出現(xiàn)這種死鎖的情況。
解決方法:
1、對于按鈕等控件,點擊后使其立刻失效,不讓用戶重復(fù)點擊,避免對同時對同一條記錄操作。
2、使用樂觀鎖進行控制。樂觀鎖大多是基于數(shù)據(jù)版本(version)記錄機制實現(xiàn)。即為數(shù)據(jù)增加一個版本標(biāo)識,在基于數(shù)據(jù)庫表的版本解決方案中,一般是通過為數(shù)據(jù)庫增加一個“version”字段來實現(xiàn)。讀取處數(shù)據(jù)時,將此版本號一同讀出,之后更新時,對此版本號加一。此時,將提交的數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息進行比對,如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當(dāng)前版本號,則予以更新,否則認(rèn)為是過期數(shù)據(jù)。樂觀鎖機制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷(用戶A和用戶B操作過程中,都沒有對數(shù)據(jù)庫加鎖),大大提升了大并發(fā)量下的系統(tǒng)整體性表現(xiàn)。 Hibernate在其數(shù)據(jù)訪問引擎中內(nèi)置了樂觀鎖實現(xiàn)。需要注意的是,由于樂觀鎖機制是我們的系統(tǒng)中實現(xiàn),來自外部系統(tǒng)的用戶更新操作不受我們系統(tǒng)的控制,因此可能會造成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。
3、使用悲觀鎖進行控制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機制實現(xiàn),如Oracle的select.......for update語句,以保證操作最大程度的獨占性。但隨之而來的就是數(shù)據(jù)庫性能的大量開銷,特別是對長事務(wù)而言,這樣的開銷往往無法承受。如一個金融系統(tǒng),當(dāng)某個操作員讀取用戶的數(shù)據(jù),并在讀出的用戶數(shù)據(jù)的基礎(chǔ)上進行修改時(如更改用戶帳戶余額),如果采用悲觀鎖機制,也就意味整個操作過程中(從操作員讀出數(shù)據(jù)、開始修改直至提交修改結(jié)果的全過程,甚至還包括操作員中途去煮咖啡的時間),數(shù)據(jù)庫記錄始終處于加鎖狀態(tài),可以想見,如果面對成百上千個并發(fā),這樣的情況將導(dǎo)致災(zāi)難性的結(jié)果。所以,采用悲觀鎖進行控制時一定要考慮清楚。
死鎖的第三種情況
如果在事務(wù)種執(zhí)行了一條不滿足條件的update語句,則執(zhí)行全表掃描,把行級鎖上升為表級鎖,多個這樣的事務(wù)執(zhí)行之后,就很容易發(fā)生死鎖和阻塞。類似的情況還有當(dāng)表種的數(shù)據(jù)量非常龐大而索引建的過少或不合適的時候,使得經(jīng)常發(fā)生全表掃描,最終應(yīng)用系統(tǒng)會越來越慢,最終發(fā)生阻塞或死鎖。
解決方法:
SQL語句中不要使用太復(fù)雜的關(guān)聯(lián)多表的查詢;使用“執(zhí)行計劃”對SQL語句進行 分析,對于有全表掃描的SQL語句,建立相應(yīng)的索引進行優(yōu)化。
***查詢死鎖表以及解鎖表***
通過select * from v$locked_object
可以獲得被鎖的對象的object_id及產(chǎn)生鎖的會話sid,通過查詢結(jié)果中的object_id,可以查詢到具體被鎖的對象。
鎖有以下幾種模式:
0:none
1:null 空
2:Row-S 行共享(RS / S鎖):共享表鎖
3:Row-X 行專用(RX / X鎖):用于行的修改
4:Share 共享鎖(S):阻止其他DML操作
5:S/Row-X 共享行專用(SRX):阻止其他事務(wù)操作
6:exclusive 專用(X):獨立訪問使用
數(shù)字越大鎖級別越高, 影響的操作越多。
一般的查詢語句如select ... from ... ;是小于2的鎖, 有時會在v$locked_object出現(xiàn)。
select ... from ... for update; 是2的鎖。
當(dāng)對話使用for update子串打開一個游標(biāo)時,
所有返回集中的數(shù)據(jù)行都將處于行級(Row-X)獨占式鎖定,
其他對象只能查詢這些數(shù)據(jù)行,不能進行update、delete或select...for update操作。
insert / update / delete ... ; 是3的鎖。
沒有commit之前插入同樣的一條記錄會沒有反應(yīng),
因為后一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續(xù)工作。
創(chuàng)建索引的時候也會產(chǎn)生3,4級別的鎖。
locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作會提示ora-00054錯誤。
有主外鍵約束時 update / delete ... ; 可能會產(chǎn)生4,5的鎖。
DDL語句時是6的鎖。
以DBA角色, 查看當(dāng)前數(shù)據(jù)庫里鎖的情況可以用如下SQL語句:
select object_id,session_id,locked_mode from v$locked_object;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有長期出現(xiàn)的一列,可能是沒有釋放的鎖。
我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖:
分享名稱:oracle如何寫悲觀鎖,oracle悲觀鎖和樂觀
當(dāng)前URL:http://www.rwnh.cn/article18/dscohdp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供ChatGPT、網(wǎng)站維護、企業(yè)網(wǎng)站制作、靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計、品牌網(wǎng)站制作
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)