在联机事务处理(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
