数据库锁表与解锁，以及锁表原因

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