您的位置:首页 > 数据库 > Oracle

Oracle 动态性能视图之V$LOCK

2016-05-17 09:32 477 查看


Oracle 动态性能视图之V$LOCK

 (2011-06-23 15:37:51)


转载▼

标签: 


oracle

 


vlock

 


杂谈

分类: DataBase
今天测试中执行一条SQL语句,执行了十多分钟也没结果,后来想到有可能是表被锁了,一查,果然是。特将网上查到的资料汇总下,以备后用。

 

  V$LOCK列出Oracle 服务器当前拥有的锁以及未完成的锁或栓锁请求。如果你觉着session在等待等待事件队列那你应该检查本视图。如果你发现session在等待一个锁。那么按如下先后顺序:

1.使用V$LOCK找出session持有的锁。

2.使用V$SESSION找出持有锁或等待锁的session执行的sql语句。

3.使用V$SESSION_WAIT找出什么原因导致session持有锁堵塞。

4.使用V$SESSION获取关于持有锁的程序和用户的更多信息。

V$LOCK定义:

Name           Null        Type    

----------   ----------   ----------

ADDR                       RAW(0)

KADDR                      RAW(0)

SID                        NUMBER

TYPE                       VARCHAR2(2)

ID1                        NUMBER

ID2                        NUMBER

LMODE                      NUMBER

REQUEST                    NUMBER

CTIME                      NUMBER

BLOCK                      NUMBER

V$LOCK中的常用列

·SID:表示持有锁的会话信息。

·TYPE:表示锁的类型。值包括TM和TX等。

·LMODE:表示会话等待的锁模式的信息。用数字0-6表示,和表1相对应。

·REQUEST:表示session请求的锁模式的信息。

·ID1,ID2:表示锁的对象标识。

公共锁类型

  在Oracle数据库中,DML锁主要包括TM锁和TX锁,其中TM锁称为表级锁,TX锁称为事务锁或行级锁。

  当Oracle执行DML语句时,系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后,系统再自动申请TX类型的锁,并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志,而只需检查TM锁模式的相容性即可,大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式,在数据库中用0-6来表示。不同的SQL操作产生不同类型的TM锁,如下表1。

TX:行级锁,事务锁

·在改变数据时必须是排它模式(mode 6)。

·每一个活动事务都拥有一个锁。它将在事务结束(commit/rollback)时释放。

·如果一个块包括的列被改变而没有ITL(interested transaction list)槽位(entries),那么session将锁置于共享模式(mode 4)。当session获得块的ITL槽位时释放。

·当一个事务首次发起一个DML语句时就获得一个TX锁,该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行DML语句时,第一个会话在该条记录上加锁,其他的会话处于等待状态。当第一个会话提交后,TX锁被释放,其他会话才可以加锁。

·指出回滚段和事务表项

 按下列项以避免竞争:

  ·避免TX-6类型竞争,需要根据您的应用而定。

  ·避免TX-4类型竞争,可以考虑增加对象INITRANS参数值。

TM:表级锁

·数据库执行任何DDL语句时必须是排它模式;例如,alter table,drop table。

·执行像insert,update,delete这类DML语句时处于共享模式。它防止其它session对同一个对象同时执行ddl语句。

·任何对象拥有正被改变的数据,TM锁都将必须存在。

·锁指向对象。

  在TM队列避免竞争,可以考虑屏蔽对象表级锁,屏蔽表级锁防止对象执行任何ddl语句。

ST:空间事务锁

·每个数据库(非实例)拥有一个ST锁。

·除了本地管理表空间,在space管理操作(新建或删除extents)时必须是排它模式。

·对象creation, dropping, extension, 以及truncation都处于这种锁

·多数公共原因的争夺,是在磁盘排序(并非使用真正的临时表空间)或回滚段扩展或收缩。

 按如下项以避免竞争:

  ·使用真正的临时表空间(true temporary tablespaces),利用临时文件。临时段在磁盘排序之后并不创建或删除。

  ·使用本地管理表空间。

  ·指定回滚段避免动态扩展和收缩,或使用自动undo management。

  ·避免应用执行创建或删除数据库对象。

UL:用户定义锁用户可以自定义锁。内容较多并与此节关系不大,略过。

示例:如何查找TX锁并解锁

 窗口1:

SQL> conn myfmis/myfmis

已连接。

SQL> update xtdwcs set MC='单位本部ok' where dh='0114';

窗口2:

SQL> conn myfmis/myfmis

已连接。

SQL> update xtdwcs set MC='单位本部ok' where dh='0114';

 

处理过程:

查看是否有session阻塞:

select * from v$lock where BLOCK=1;

ADDR     KADDR    SID TYPE ID1    ID2 LMODE REQUEST CTIME BLOCK

1FE0C654 1FE0C770 151 TX   131115 520 6     0       669    1

查看TX锁的SID与Serial#:

select sid,serial#,username,state,blocking_session_status,blocking_session from v$session where event like'%TX%';

SID SERIAL# USERNAME STATE   BLOCKING_SESSION_STATUS BLOCKING_SESSION

137  6      FMISMAIN WAITING  VALID                  150

临时KILL这个session:

第一:kill掉137,6,则是kill掉被block的session。

alter system kill session '137,6';

第二:kill掉150,则是kill掉之前block别人的session。

因此通过前面的137,6所查到的SQL语句,则是后面运行被等待的SQL语句,而不是阻塞别人的SQL语句。

如果要查找原因,操作如下:

查找相应的SQL语句:

select a.sql_text from v$sqlarea a,v$session b where a.sql_id=b.sql_id

select a.sql_text from v$sqlarea a,v$session b where a.sql_id=b.sql_id and b.event like'%TX%'
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: