在聯機事務處理(OLTP)的數據庫應用系統中，多用戶、多任務的並發性是系統最重要的技術指標之一。為了提高並發性，目前大部分RDBMS都采用加鎖技術。然而由於現實環境的復雜性，使用加鎖技術又不可避免地產生了死鎖問題。因此如何合理有效地使用加鎖技術，最小化死鎖是開發聯機事務處理系統的關鍵。
死鎖產生的原因
在聯機事務處理系統中，造成死機主要有兩方面原因。一方面，由於多用戶、多任務的並發性和事務的完整性要求，當多個事務處理對多個資源同時訪問時，若雙方已鎖定一部分資源但也都需要對方已鎖定的資源時，無法在有限的時間內完全獲得所需的資源，就會處於無限的等待狀態，從而造成其對資源需求的死鎖。
另一方面，數據庫本身加鎖機制的實現方法不同，各數據庫系統也會產生其特殊的死鎖情況。如在Sybase SQL Server 11中，最小鎖為2K一頁的加鎖方法，而非行級鎖。如果某張表的記錄數少且記錄的長度較短(即記錄密度高，如應用系統中的系統配置表或系統參數表就屬於此類表)，被訪問的頻率高，就容易在該頁上產生死鎖。
容易發生死鎖的幾種情況如下:
1>不同的存儲過程、觸發器、動態SQL語句段按照不同的順序同時訪問多張表;
2>在交換期間添加記錄頻繁的表，但在該表上使用了非群集索引(non-clustered);
3>表中的記錄少，且單條記錄較短，被訪問的頻率較高；
4>整張表被訪問的頻率高(如代碼對照表的查詢等)。
以上死鎖情況的對應處理方法如下:
1>在系統實現時應規定所有存儲過程、觸發器、動態SQL語句段中，對多張表的操作總是使用同一順序。如：有兩個存儲過程proc1、proc2，都需要訪問三張表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的順序進行訪問，那么，proc2也應該按照以上順序訪問這三張表。
2>對在交換期間添加記錄頻繁的表，使用群集索引(clustered)，以減少多個用戶添加記錄到該表的最后一頁上，在表尾產生熱點，造成死鎖。這類表多為往來賬的流水表，其特點是在交換期間需要在表尾追加大量的記錄，並且對已添加的記錄不做或較少做刪除操作。
3>對單張表中記錄數不太多，且在交換期間select或updata較頻繁的表可使用設置每頁最大行的辦法，減少數據在表中存放的密度，模擬行級鎖，減少在該表上死鎖情況的發生。這類表多為信息繁雜且記錄條數少的表。
如：系統配置表或系統參數表。在定義該表時添加如下語句：
with max_rows_per_page=1
在存儲過程、觸發器、動態SQL語句段中，若對某些整張表select操作較頻繁，則可能在該表上與其他訪問該表的用戶產生死鎖。對於檢查賬號是否存在，但被檢查的字段在檢查期間不會被更新等非關鍵語句，可以采用在select命令中使用at isolation read uncommitted子句的方法解決。該方法實際上降低了select語句對整張表的鎖級別，提高了其他用戶對該表操作的並發性。在系統高負荷運行時，該方法的效果尤為顯著。
如：
select * from titles at isolation read uncommitted
對流水號一類的順序數生成器字段，可以先執行updata流水號字段+1，然后再執行select獲取流水號的方法進行操作。
select *from v$locked_object;
可以獲得被鎖的對象的object_id及產生鎖的會話sid。
通過查詢結果中的object_id，可以查詢到具體被鎖的對象
再給你看看我查到的一些關於鎖的資料：
鎖有以下幾種模式:
0：none
1：null 空
2：Row-S 行共享(RS)：共享表鎖
3：Row-X 行專用(RX)：用於行的修改
4：Share 共享鎖(S)：阻止其他DML操作
5：S/Row-X 共享行專用(SRX)：阻止其他事務操作
6：exclusive 專用(X)：獨立訪問使用
數字越大鎖級別越高, 影響的操作越多。
一般的查詢語句如select ... from ... ;是小於2的鎖, 有時會在v$locked_object出現。
select ... from ... for update; 是2的鎖。
當對話使用for update子串打開一個游標時，
所有返回集中的數據行都將處於行級(Row-X)獨占式鎖定，
其他對象只能查詢這些數據行，不能進行update、delete或select...for update操作。
insert / update / delete ... ; 是3的鎖。
沒有commit之前插入同樣的一條記錄會沒有反應,
因為后一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續工作。
創建索引的時候也會產生3,4級別的鎖。
locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作會提示ora-00054錯誤。
有主外鍵約束時 update / delete ... ; 可能會產生4,5的鎖。
DDL語句時是6的鎖。
以DBA角色, 查看當前數據庫里鎖的情況可以用如下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;
如果有長期出現的一列，可能是沒有釋放的鎖。
我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：
alter system kill session 'sid,serial#';
如果出現了鎖的問題, 某個DML操作可能等待很久沒有反應。
當你采用的是直接連接數據庫的方式，
也不要用OS系統命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，
因為一個用戶進程可能產生一個以上的鎖, 殺OS進程並不能徹底清除鎖的問題。
記得在數據庫級別用alter system kill session 'sid,serial#';殺掉不正常的鎖。
這里還講了一些：
http://zhidao.baidu.com/question/17561017.html?si=3
一、mysql
鎖定表：LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]
解鎖表：UNLOCK TABLES
例子：
LOCK TABLES table1 WRITE ,table2 READ ... 更多表枷鎖;
說明：1、READ 鎖代表 其他用戶只能讀 不能其他操作
2、WRITE鎖代表：其他用戶不能任何操作（包括讀）
查看那些表被鎖：show OPEN TABLES where In_use > 0;
全局加鎖：FLUSH TABLES WITH READ LOCK（這個命令是全局讀鎖定，執行了命令之后所有庫所有表都被鎖定只讀。解鎖也是：UNLOCK TABLES ）
二、oracle
--行級鎖定（同樣對 mysql起作用）
通過 ：select * from tableName t for update 或 select * from tableName t where id =1 for update
前者鎖定整個表，后者多頂 id=1的一行數據（有主鍵，並且指定 主鍵=值 的只鎖定指定行）
說明：通過 select ... for update 后 其他用戶只能讀 不能其他操作，鎖定者通過 commit或 rollback命令 自動解鎖，或使用 本文的 解鎖方式（will）！
--表級鎖定
lock table <table_name> in <lock_mode> mode [nowait]
其中:
lock_mode 是鎖定模式
nowait關鍵字用於防止無限期的等待其他用戶釋放鎖
五種模式如下（1到5 級別越來越高，限制越來越大）：
1、行共享（row share,rs）:允許其他用戶訪問和鎖定該表，但是禁止排他鎖定整個表
2、排他鎖（row exclusive ,rx）:與行共享模式相同，同時禁止其他用戶在此表上使用共享鎖。使用select ... for update語句會在表上自動應用行排他鎖
3、共享（share ,s）:共享鎖將鎖定表，僅允許其他用戶查詢表中的行，但不允許插入、更新、刪除行。多個用戶可以在同一表中放置共享鎖，即允許資源共享，，因此得名“共享鎖”。例如：如果用戶每天都需要在結賬時更新日銷售額表，則可以在更新該表時使用共享鎖以確保數據的一致性。
4、共享排他鎖（share row exclusive,srx）：執行比共享鎖更多的限制。防止其他事務在表上應用共享鎖，、共享排他鎖以及排他鎖。
5、排他（exclusive,x）：對表執行最大的限制。除了允許其他用戶查詢該表記錄，排他鎖防止其他事務對表做任何更改或在表上應用任何類型的鎖。
實例：
lock table table_Name in exclusive mode；
要解鎖需要 鎖定人 執行 commit 或 rollback 或者 用本文的 解鎖方式（will）！
--查詢鎖表
SELECT /*+ rule */
S.USERNAME,
DECODE(L.TYPE, 'TM', 'TABLE LOCK', 'TX', 'ROW LOCK', NULL) LOCK_LEVEL,
O.OWNER,
O.OBJECT_NAME,
O.OBJECT_TYPE,
S.SID,
S.SERIAL#,
S.TERMINAL,
S.MACHINE,
S.PROGRAM,
S.OSUSER
FROM V$SESSION S, V$LOCK L, DBA_OBJECTS O
WHERE L.SID = S.SID
AND L.ID1 = O.OBJECT_ID(+)
AND S.USERNAME IS NOT NULL;
--查詢狀態
SELECT SESSION_ID SID,
OWNER,
NAME,
TYPE,
MODE_HELD HELD,
MODE_REQUESTED REQUEST
FROM DBA_DDL_LOCKS
WHERE NAME = 'DRAG_DATA_FROM_LCAM';
SELECT T1.SID, T1.SERIAL#, T2.SQL_TEXT
FROM V$SESSION T1, V$SQL T2
WHERE T1.SQL_ID = T2.SQL_ID
AND T2.SQL_TEXT LIKE '%DRAG_DATA_FROM_LCAM%';
SELECT DISTINCT P.SPID, S.SID, S.SERIAL# FROM V$DB_OBJECT_CACHE OC,
V$OBJECT_DEPENDENCY OD,
DBA_KGLLOCK W,
V$SESSION S,
V$PROCESS P
WHERE OD.TO_OWNER = OC.OWNER
AND OD.TO_NAME = OC.NAME
AND OD.TO_ADDRESS = W.KGLLKHDL
AND W.KGLLKUSE = S.SADDR
AND P.ADDR = S.PADDR
AND OC.NAME = UPPER('drag_data_from_lcam');
Oracle的鎖表與解鎖
SELECT /*+ rule */ s.username,
decode(l.type,'TM','TABLE LOCK',
'TX','ROW LOCK',
NULL) LOCK_LEVEL,
o.owner,o.object_name,o.object_type,
s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser
FROM v$session s,v$lock l,dba_objects o
WHERE l.sid = s.sid
AND l.id1 = o.object_id(+)
AND s.username is NOT Null
--kill session語句 （說明 ：下面的 50是查詢結果中sid字段值，492是serial#字段值）
alter system kill session'50,492'; （需要dba權限）
--以下幾個為相關表
SELECT * FROM v$lock;
SELECT * FROM v$sqlarea;
SELECT * FROM v$session;
SELECT * FROM v$process ;
SELECT * FROM v$locked_object;
SELECT * FROM all_objects;
SELECT * FROM v$session_wait;
--1.查出鎖定object的session的信息以及被鎖定的object名
SELECT l.session_id sid, s.serial#, l.locked_mode,l.oracle_username,
l.os_user_name,s.machine, s.terminal, o.object_name, s.logon_time
FROM v$locked_object l, all_objects o, v$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid
ORDER BY sid, s.serial# ;
--2.查出鎖定表的session的sid, serial#,os_user_name, machine name, terminal和執行的語句
--比上面那段多出sql_text和action
SELECT l.session_id sid, s.serial#, l.locked_mode, l.oracle_username, s.user#,
l.os_user_name,s.machine, s.terminal,a.sql_text, a.action
FROM v$sqlarea a,v$session s, v$locked_object l
WHERE l.session_id = s.sid
AND s.prev_sql_addr = a.address
ORDER BY sid, s.serial#;
--3.查出鎖定表的sid, serial#,os_user_name, machine_name, terminal，鎖的type,mode
SELECT s.sid, s.serial#, s.username, s.schemaname, s.osuser, s.process, s.machine,
s.terminal, s.logon_time, l.type
FROM v$session s, v$lock l
WHERE s.sid = l.sid
AND s.username IS NOT NULL
ORDER BY sid;
這個語句將查找到數據庫中所有的DML語句產生的鎖，還可以發現，
任何DML語句其實產生了兩個鎖，一個是表鎖，一個是行鎖。
殺鎖命令
alter system kill session 'sid,serial#'
SELECT /*+ rule */ s.username,
decode(l.type,'TM','TABLE LOCK',
'TX','ROW LOCK',
NULL) LOCK_LEVEL,
o.owner,o.object_name,o.object_type,
s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser
FROM v$session s,v$lock l,dba_objects o
WHERE l.sid = s.sid
AND l.id1 = o.object_id(+)
AND s.username is NOT NULL
如果發生了鎖等待，我們可能更想知道是誰鎖了表而引起誰的等待
以下的語句可以查詢到誰鎖了表，而誰在等待。
以上查詢結果是一個樹狀結構，如果有子節點，則表示有等待發生。
如果想知道鎖用了哪個回滾段，還可以關聯到V$rollname，其中xidusn就是回滾段的USN
col user_name format a10
col owner format a10
col object_name format a10
col object_type format a10
SELECT /*+ rule */ lpad(' ',decode(l.xidusn ,0,3,0))||l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#
FROM v$locked_object l,dba_objects o,v$session s
WHERE l.object_id=o.object_id
AND l.session_id=s.sid
ORDER BY o.object_id,xidusn DESC
