oracle锁表处理

 

 

  假若有悠久出现的一列,恐怕是没有自由的锁。 
   
  我们可以用上面SQL语句杀掉长时间并未自由非不荒谬的锁:

 

 

  select object_id,session_id,locked_mode from v$locked_object;

锁表查询SQL
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;

  alter system kill session ‘sid,serial#’;

select pro.spid from v$session ses,v$process pro where ses.sid=XX and
ses.paddr=pro.addr;

  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;

 

select username,lockwait,status,machine,program from v$session where sid
in
(select session_id from v$locked_object)

Oracle里锁有以下二种格局: 

 

*  0:none 
  1:null 空 
  2:Row-S 行共享(路虎极光S):共享表锁 
  3:Row-X 行专用(君越X):用于行的改动 
  4:Share 共享锁(S):阻止其余DML操作 
  5:S/Row-X 共享行专用(S凯雷德X):阻止其余工作操作 
  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语句:*

其间spid是其一进度的历程号,kill掉那个Oracle进度

–查询什么SQL引起的锁表
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#;

–查出oracle当前的被锁对象
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#;

其间sid用死锁的sid替换: exit

–释放SESSION SQL:
–alter system kill session ‘sid, serial#’;
如:  ALTER system kill session ’23, 1647′;

如果还不可以缓解:

当工作得到行锁后,此业务也将自行获取该行的表锁(共享锁),以预防其余事情进行DDL语句影响记录行的换代。事务也能够在开展进程中拿走共享锁或排它锁,唯有当事情突显采纳LOCK
TABLE语句突显的概念一个排它锁时,事务才会获得表上的排它锁,也可使用LOCK
TABLE突显的概念一个表级的共享锁
,所以行锁的时候自个儿还的拿个表锁,免得其余人该了自作者的表结构依旧去除了本身的表。

–查询死锁,并可以看出死锁的机器是那一台

–kill掉当前的锁对象足以为
alter system kill session ‘sid, s.serial#‘;

 

死锁的规律:当对于数据库某个表的某一列做创新或删除等操作,执行完结后该条语句不提交,另一条对于这一列数据做革新操作的口舌在履行的时候就会处于等候状态,此时的景观是这条语句一向在实施,但直接没有举办成功,也未曾报错。

  若是出现了锁的题材, 某个DML操作只怕等待很久没有反应。 
   
  当你使用的是一贯连接数据库的方法, 
  也毫不用OS系统命令 $kill process_num 或者 $kill -9
process_num来终止用户连接, 
  因为一个用户进度大概爆发一个上述的锁,
杀OS进度并无法彻底清除锁的题材。 
   
  记得在数据库级别用alter system kill session
‘sid,serial#’;杀掉不健康的锁。

ps -ef|grep spid