DML鎖又可以分為，行鎖、表鎖、死鎖
站在用戶的角度思考問題，與客戶深入溝通，找到西鄉(xiāng)網(wǎng)站設(shè)計與西鄉(xiāng)網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名申請、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋西鄉(xiāng)地區(qū)。
-行鎖：當(dāng)事務(wù)執(zhí)行數(shù)據(jù)庫插入、更新、刪除操作時，該事務(wù)自動獲得操作表中操作行的排它鎖。
-表級鎖：當(dāng)事務(wù)獲得行鎖后，此事務(wù)也將自動獲得該行的表鎖(共享鎖),以防止其它事務(wù)進行DDL語句影響記錄行的更新。事務(wù)也可以在進行過程中獲得共享鎖或排它鎖，只有當(dāng)事務(wù)顯示使用LOCK TABLE語句顯示的定義一個排它鎖時，事務(wù)才會獲得表上的排它鎖,也可使用LOCK TABLE顯示的定義一個表級的共享鎖(LOCK TABLE具體用法請參考相關(guān)文檔)。
-死鎖：當(dāng)兩個事務(wù)需要一組有沖突的鎖，而不能將事務(wù)繼續(xù)下去的話，就出現(xiàn)死鎖。
如事務(wù)1在表A行記錄#3中有一排它鎖，并等待事務(wù)2在表A中記錄#4中排它鎖的釋放，而事務(wù)2在表A記錄行#4中有一排它鎖，并等待事務(wù)1在表A中記錄#3中排它鎖的釋放，事務(wù)1與事務(wù)2彼此等待，因此就造成了死鎖。死鎖一般是因拙劣的事務(wù)設(shè)計而產(chǎn)生。
死鎖只能使用SQL下:alter system kill session "sid,serial#"；或者使用相關(guān)操作系統(tǒng)kill進程的命令，如UNIX下kill -9 sid,或者使用其它工具殺掉死鎖進程。
+DDL鎖又可以分為：排它DDL鎖、共享DDL鎖、分析鎖
-排它DDL鎖：創(chuàng)建、修改、刪除一個數(shù)據(jù)庫對象的DDL語句獲得操作對象的 排它鎖。如使用alter table語句時，為了維護數(shù)據(jù)的完成性、一致性、合法性，該事務(wù)獲得一排它DDL鎖。
-共享DDL鎖：需在數(shù)據(jù)庫對象之間建立相互依賴關(guān)系的DDL語句通常需共享獲得DDL鎖。
如創(chuàng)建一個包，該包中的過程與函數(shù)引用了不同的數(shù)據(jù)庫表，當(dāng)編譯此包時，該事務(wù)就獲得了引用表的共享DDL鎖。
-分析鎖：ORACLE使用共享池存儲分析與優(yōu)化過的SQL語句及PL/SQL程序，使運行相同語句的應(yīng)用速度更快。一個在共享池中緩存的對象獲得它所引用數(shù)據(jù)庫對象的分析鎖。分析鎖是一種獨特的DDL鎖類型，ORACLE使用它追蹤共享池對象及它所引用數(shù)據(jù)庫對象之間的依賴關(guān)系。當(dāng)一個事務(wù)修改或刪除了共享池持有分析鎖的數(shù)據(jù)庫對象時，ORACLE使共享池中的對象作廢，下次在引用這條SQL/PLSQL語句時，ORACLE重新分析編譯此語句。
什么是死鎖
當(dāng)兩個（或多個）用戶互相等待被對方加鎖的資源時就會發(fā)生死鎖（deadlock）。死鎖將導(dǎo)致相關(guān)的事務(wù)停止執(zhí)行。下圖演示了產(chǎn)生死鎖的兩個事務(wù)。
如圖所示，在時間點 A，兩個事務(wù)均獲得了更新操作所需數(shù)據(jù)行上的鎖，此時兩事務(wù)均正常，能夠繼續(xù)執(zhí)行。接下來，兩個事務(wù)均要更新當(dāng)前被對方加鎖的數(shù)據(jù)。因此，在時間點 B 將發(fā)生死鎖，因為此時兩個事務(wù)都不能獲得繼續(xù)執(zhí)行或終止所需的資源。無論兩個事務(wù)等待多久，相互沖突的鎖都無法被釋放，所以此種情況被稱為死鎖。
圖：產(chǎn)生死鎖的兩個事務(wù)
檢測死鎖
數(shù)據(jù)庫能自動地檢測死鎖的情況，回滾造成死鎖的某個語句，以便釋放沖突的行級鎖，從而解決死鎖問題。數(shù)據(jù)庫將向執(zhí)行了語句級回滾的事務(wù)返回一個錯誤信息。
避免死鎖
如果兩個事務(wù)需要訪問相同的一組表，那么在兩個事務(wù)中按相同的順序?qū)@組表加鎖通常能避免多表死鎖。例如，如果系統(tǒng)中的一個主表及一個明細(xì)表都需要更新時，開發(fā)者應(yīng)該遵從一定的規(guī)則，如先對主表加鎖，再對明細(xì)表加鎖。如果能夠仔細(xì)設(shè)計類似的規(guī)則并嚴(yán)格執(zhí)行，就能從根本上杜絕死鎖的產(chǎn)生。 如果開發(fā)者預(yù)先知道需要在同一事務(wù)內(nèi)對一系列資源加鎖，那么應(yīng)考慮首先對排他性最高的資源加鎖。
關(guān)于數(shù)據(jù)庫死鎖的檢查方法
一、數(shù)據(jù)庫死鎖的現(xiàn)象
程序在執(zhí)行的過程中，點擊確定或保存按鈕，程序沒有響應(yīng)，也沒有出現(xiàn)報錯。
二、死鎖的原理
當(dāng)對于數(shù)據(jù)庫某個表的某一列做更新或刪除等操作，執(zhí)行完畢后該條語句不提
交，另一條對于這一列數(shù)據(jù)做更新操作的語句在執(zhí)行的時候就會處于等待狀態(tài)，
此時的現(xiàn)象是這條語句一直在執(zhí)行，但一直沒有執(zhí)行成功，也沒有報錯。
三、死鎖的定位方法
通過檢查數(shù)據(jù)庫表，能夠檢查出是哪一條語句被死鎖，產(chǎn)生死鎖的機器是哪一臺。
1）用dba用戶執(zhí)行以下語句
select username,lockwait,status,machine,program from v$session where sid in
(select session_id from v$locked_object)
如果有輸出的結(jié)果，則說明有死鎖，且能看到死鎖的機器是哪一臺。字段說明：
Username：死鎖語句所用的數(shù)據(jù)庫用戶；
Lockwait：死鎖的狀態(tài)，如果有內(nèi)容表示被死鎖。
Status： 狀態(tài)，active表示被死鎖
Machine： 死鎖語句所在的機器。
Program： 產(chǎn)生死鎖的語句主要來自哪個應(yīng)用程序。
2）用dba用戶執(zhí)行以下語句，可以查看到被死鎖的語句。
select sql_text from v$sql where hash_value in
(select sql_hash_value from v$session where sid in
(select session_id from v$locked_object))
四、死鎖的解決方法
一般情況下，只要將產(chǎn)生死鎖的語句提交就可以了，但是在實際的執(zhí)行過程中。用戶可
能不知道產(chǎn)生死鎖的語句是哪一句?？梢詫⒊绦蜿P(guān)閉并重新啟動就可以了。
經(jīng)常在Oracle的使用過程中碰到這個問題，所以也總結(jié)了一點解決方法。
1）查找死鎖的進程：
sqlplus "/as sysdba" (sys/change_on_install)
SELECT s.username,l.OBJECT_ID,l.SESSION_ID,s.SERIAL#,
l.ORACLE_USERNAME,l.OS_USER_NAME,l.PROCESS
FROM V$LOCKED_OBJECT l,V$SESSION S WHERE l.SESSION_ID=S.SID;
2）kill掉這個死鎖的進程：
alter system kill session ‘sid,serial#’; （其中sid=l.session_id）
alter system kill session '710,35184'; （其中sid=l.session_id）
3）如果還不能解決：
select pro.spid from v$session ses,v$process pro where ses.sid=XX and ses.paddr=pro.addr;
其中sid用死鎖的sid替換: exit
ps -ef|grep spid
其中spid是這個進程的進程號，kill掉這個Oracle進程
from:
select A.SQL_TEXT, B.USERNAME, C.OBJECT_ID, C.SESSION_ID,
B.SERIAL#, C.ORACLE_USERNAME,C.OS_USER_NAME,C.Process,
''''||C.Session_ID||','||B.SERIAL#||''''
from v$sql A, v$session B, v$locked_object C
where A.HASH_VALUE = B.SQL_HASH_VALUE and
B.SID = C.Session_ID
你好：這個死鎖沒辦法完全避免，盡量的話在做事物提交的時候，提交完成后在進行其余的同一個表的操作，再就是insert、update等操作盡量能減少就減少。其實正常情況下是很少出現(xiàn)死鎖的。
1、在sql語句后面加上for update可以獲得行鎖。
2、捕捉返回的sqlcode 和 sqlerrmc 可以得到返回值和錯誤信息。
---
以上，希望對你有所幫助。
查詢鎖表
SELECT object_name, machine, s.sid, s.serial#
FROM gv$locked_object l, dba_objects o, gv$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid;
2解鎖
--釋放SESSION SQL:
--alter system kill session 'sid, serial#';
ALTER system kill session '23, 1647';
3鎖表原因分析
1.對數(shù)據(jù)庫操作update,insert,delete時候,數(shù)據(jù)庫無法更新,操作等待時長,操作結(jié)果不發(fā)生改變
2.在程序中,底層（數(shù)據(jù)訪問層）操作時候,不成功,數(shù)據(jù)庫連接超時,無法操作,或者操作等待時長等現(xiàn)象
【加鎖的原理】：比如一個操作在進行修改一表,它沒完成，另一個操作也操作這張表時候就需要等待，前面操作結(jié)束之后才可進行操作。
4鎖表分類以及如何避免鎖表
Oracle鎖表 行級鎖 表級鎖
---- 行被排他鎖定
----在某行的鎖被釋放之前，其他用戶不能修改此行 ----使用 commit 或 rollback 命令釋放鎖
----Oracle 通過使用 INSERT、UPDATE 和 SELECT…FOR UPDATE 語句自動獲取行級鎖
SELECT…FOR UPDATE 子句 ―在表的一行或多行上放置排他鎖 ―用于防止其他用戶更新該行
―可以執(zhí)行除更新之外的其他操作
―select * from goods where gid=1001 ―for update of gname;
―只有該用戶提交事務(wù)，其他用戶才能夠更新gname
FOR UPDATE WAIT 子句 ―Oracle9i 中的新增功能 ―防止無限期地等待鎖定的行 ―等待間隔必須指定為數(shù)值文字
―等待間隔不能是表達式、賦值變量或 PL/SQL 變量
―select * from goods where gid=1001 for update of gname wait 3 ―等待用戶釋放更新鎖的時間為3秒，否則超時。 ?表級鎖
―保護表的數(shù)據(jù)
―在多個用戶同時訪問數(shù)據(jù)時確保數(shù)據(jù)的完整性 ―可以設(shè)置為三種模式：共享、共享更新和 排他
語法：lock table table_namein mode; 共享鎖 ―鎖定表
―僅允許其他用戶執(zhí)行查詢操作 ―不能插入、更新和刪除
―多個用戶可以同時在同一表中放置此鎖 ―lock table table_name ―in share mode [nowait];
― rollback 和commit 命令釋放鎖 ― nowait 關(guān)鍵字告訴其他用戶不用等待 共享更新鎖
―鎖定要被更新的行
―允許其他用戶同時查詢、插入、更新未被鎖定的行
―在 SELECT 語句中使用“FOR UPDATE”子句，可以強制使用共享更新鎖 ―允許多個用戶同時鎖定表的不同行
加鎖的兩種方法
lock table tab_name in share update mode; select column1,column2 from goods where goods where gid=1001
for update of column1,column2 排他鎖
―與其他兩種鎖相比，排他鎖是限制性最強的表鎖 ―僅允許其他用戶查詢數(shù)據(jù)
―不允許執(zhí)行插入、刪除和更新操作
―在同一時間僅允許一位用戶在表上放置排他鎖 ―共享鎖與此相反
lock table tab_name in exclusive mode; lock table 表名[ 表名]... in share mode [nowait]
lock table 表名[ 表名]... in exclusive mode [nowait] lock table 表名[ 表名]... in share update mode[nowait]
-----------------------------------------------------------------------------------------------
LOCK Name
LOCK — 在事務(wù)中明確地鎖定一個表 LOCK [ TABLE ] name
LOCK [ TABLE ] name IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] name IN SHARE ROW EXCLUSIVE MODE 輸入
name
要鎖定的現(xiàn)存的表．
ACCESS SHARE MODE
注意: 這個鎖模式對被查詢的表自動生效。
這是最小限制的鎖模式，只與 ACCESS EXCLUSIVE 模式?jīng)_突。 它用于保護被查詢的表免于被并行的 ALTER TABLE， DROP TABLE 和 VACUUM 對同一表操作的語句修改。
ROW SHARE MODE
注意: 任何 SELECT...FOR UPDATE 語句執(zhí)行時自動生效。 因為它是一個共享鎖，以后可能更新為 ROW EXCLUSIVE 鎖。
與 EXCLUSIVE 和 ACCESS EXCLUSIVE 鎖模式?jīng)_突。
ROW EXCLUSIVE MODE
注意: 任何 UPDATE， DELETE和 INSERT 語句執(zhí)行時自動生效。
與 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE 和 ACCESS EXCLUSIVE 模式?jīng)_突。
SHARE MODE
注意: 任何 CREATE INDEX 語句執(zhí)行時自動附加。 共享鎖住整個表．
與 ROW EXCLUSIVE，SHARE ROW EXCLUSIVE，EXCLUSIVE 和 ACCESS EXCLUSIVE 模式?jīng)_突。這個模式防止一個表被并行更新。
SHARE ROW EXCLUSIVE MODE
注意: 這個模式類似 EXCLUSIVE MODE，但是允許其他事務(wù)的 SHARE ROW 鎖．
-----------------------------------------------------------------------------------------------
與 ROW EXCLUSIVE，SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE 和 ACCESS EXCLUSIVE 模式?jīng)_突。
EXCLUSIVE MODE
注意: 這個模式同樣比 SHARE ROW EXCLUSIVE 更有約束力． 它阻塞所有并行的 ROW SHARE/SELECT... FOR UPDATE 查詢。
與 ROW EXCLUSIVE，SHARE，SHARE ROW EXCLUSIVE，EXCLUSIVE 和 ACCESS EXCLUSIVE 模式?jīng)_突。
ACCESS EXCLUSIVE MODE
注意: 由語句 ALTER TABLE, DROP TABLE，VACUUM 執(zhí)行時自動生效。這是最嚴(yán)格的約束鎖，它與所有其他的鎖 模式?jīng)_突并且保護一個被鎖定的表不被任何其他并行的操作更改。
注意: 一個不合格的 LOCK TABLE 同樣要求這個鎖模式 （例如，一條沒有顯式鎖模式選項的命令）。
輸出
LOCK TABLE 成功鎖定后的返回．
ERROR name: Table does not exist. 如果name 不存在，返回此信息．
描述
LOCK TABLE 控制一次事務(wù)的生命期內(nèi)對某表的并行訪問． Postgres 在可能的情況下盡可能使用最小約束的鎖模式。 LOCK TABLE 在你需要時提供更有約束力的鎖。
RDBMS 鎖定使用下面術(shù)語：
EXCLUSIVE
排它鎖，防止其他（事務(wù)）鎖的產(chǎn)生．
SHARE
允許其他（事務(wù)）共享鎖．避免 EXCLUSIVE 鎖．
ACCESS
-----------------------------------------------------------------------------------------------
鎖定表結(jié)構(gòu)．
ROW
鎖定獨立的行．
注意: 如果沒有聲明 EXCLUSIVE 或 SHARE，假設(shè)為 EXCLUSIVE．鎖存在于事務(wù)周期內(nèi)．
例如，一個應(yīng)用在 READ COMMITED 隔離級別上運行事務(wù)， 并且它需要保證在表中的數(shù)據(jù)在事務(wù)的運行過程中都存在。要實現(xiàn)這個你 可以在查詢之前對表使用 SHARE 鎖模式進行鎖定。這樣將保護數(shù)據(jù)不被 并行修改并且為任何更進一步的對表的讀操作提供實際狀態(tài)的數(shù)據(jù)， 因為 SHARE 鎖模式與任何寫操作需要的 ROW EXCLUSIVE 模式?jīng)_突，并且你的 LOCK TABLE name IN SHARE MODE 語句將等到所有并行的寫操作提交或回卷后才執(zhí)行。
注意: 當(dāng)在 SERIALIZABLE 隔離級別運行事務(wù)，而且你需要讀取真實狀態(tài)的數(shù)據(jù)時， 你必須在執(zhí)行任何 DML 語句 （這時事務(wù)定義什么樣的并行修改對它自己是可見的） 之前運行一個 LOCK TABLE 語句。
除了上面的要求外，如果一個事務(wù)準(zhǔn)備修改一個表中的數(shù)據(jù)， 那么應(yīng)該使用 SHARE ROW EXCLUSIVE 鎖模式以避免死鎖情況（當(dāng)兩個 并行的事務(wù)試圖以 SHARE 模式鎖住表然后試圖更改表中的數(shù)據(jù)時， 兩個事務(wù)（隱含的）都需要 ROW EXCLUSIVE 鎖模式，而此模式與并行的 SHARE 鎖沖突）。
繼續(xù)上面的死鎖（兩個事務(wù)彼此等待）問題， 你應(yīng)該遵循兩個通用的規(guī)則以避免死鎖條件：
事務(wù)應(yīng)該以相同的順序?qū)ο嗤膶ο笳埱箧i。
例如，如果一個應(yīng)用更新行 R1 然后更新行 R2（在同一的事務(wù)里）， 那么第二個應(yīng)用如果稍后要更新行 R1 時不應(yīng)該更新行 R2（在 同一事務(wù)里）。相反，它應(yīng)該與第一個應(yīng)用以相同的順序更新行 R1 和 R2。
事務(wù)請求兩個互相沖突的鎖模式的前提：其中一個鎖模式是自沖突的 （也就是說，一次只能被一個事務(wù)持有）。 如果涉及多種鎖模式，那么事務(wù)應(yīng)該總是最先請求最嚴(yán)格的鎖模式。
這個規(guī)則的例子在前面的關(guān)于用 SHARE ROW EXCLUSIVE 模式取代 SHARE 模式的討論中已經(jīng)給出了。 -----------------------------------------------------------------------------------------------
注意: Postgres 的確檢測死鎖， 并將回卷至少一個等待的事務(wù)以解決死鎖。
注意
LOCK 是 Postgres 語言擴展．
除了ACCESS SHARE/EXCLUSIVE 鎖模式外，所有其他 Postgres 鎖模式和 LOCK TABLE 語句都與那些在 Oracle 里面的兼容。
LOCK 只在事務(wù)內(nèi)部使用．
用法
演示在往一個外鍵表上插入時在有主鍵的表上使用 SHARE 的鎖：
BEGIN WORK;
LOCK TABLE films IN SHARE MODE; SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- 如果記錄沒有返回則回卷
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!'); COMMIT WORK;
在執(zhí)行刪除操作時對一個有主鍵的表進行 SHARE ROW EXCLUSIVE 鎖：
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE; DELETE FROM films_user_comments WHERE id IN (SELECT id FROM films WHERE rating 5); DELETE FROM films WHERE rating 5; COMMIT WORK; 兼容性 SQL92
在SQL92里面沒有LOCK TABLE ，可以使用 SET TRANSACTION 來聲明當(dāng)前事務(wù)的級別． 我們也支持這個，參閱 SET TRANSACTION 獲取詳細(xì)信息。
這種情況叫死鎖，與網(wǎng)絡(luò)質(zhì)量無關(guān)。
最大的可能就是程序的原因。
如A進程修改a表的某條記錄，修改完a表后，會繼續(xù)修改b表的某條記錄，然后提交事務(wù)。
這個時候，B進程在修改b表的那條記錄，修改完后要去修改a表的那條記錄，然后提交事務(wù)。
這樣，當(dāng)A修改完a尚未修改b，B修改完b尚未修改a的時候，就可能出現(xiàn)B進程等待A進程提交事務(wù)，A進程又在等待B進程提交事務(wù)，兩個進程一直在等。
所以死鎖就出現(xiàn)了。
重慶分公司
重慶分公司
