转：oracle几组重要的常见视图-v$latch，v$latch_children，v$lock，v$locked_object

v$latch

Oracle Rdbms应用了各种不同类型的锁定机制，latch即是其中的一种。Latch是用于保护SGA区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，

尤其和一个进程是否需要等待一个latch、需要等待多长时间有关。Latch是一种能够极快地被获取和释放的锁，它通常用于保护描述buffer cache中block的数据结构。与

每个latch相联系的还有一个清除过程，当持有latch的进程成为死进程时，该清除过程就会被调用。Latch还具有相关级别，用于防止死锁，一旦一个进程在某个级别

上得到一个latch，它就不可能再获得等同或低于该级别的latch。

本视图保存自实例启动各类栓锁的统计信息。常用于当v$session_wait中发现栓锁竞争时鉴别SGA区中问题所在区域。

　　v$latch表的每一行包括了对不同类型latch的统计，每一列反映了不同类型的latch请求的活动情况。不同类型的latch请求之间的区别在于，

当latch不可立即获得时，请求进程是否继续进行。按此分类，latch请求的类型可分为两类：willing-to-wait和immediate。

　　Willing-to-wait：是指如果所请求的latch不能立即得到，请求进程将等待一很短的时间后再次发出请求。进程一直重复此过程直到得到latch。

　　Immediate：是指如果所请求的latch不能立即得到，请求进程就不再等待，而是继续执行下去。

V$LATCH中的常用列：

　　NAME：latch名称

　　IMMEDIATE_GETS：以Immediate模式latch请求数

　　IMMEDIATE_MISSES：请求失败数

　　GETS：以Willing to wait请求模式latch的请求数

　　MISSES：初次尝试请求不成功次数

　　SPIN_GETS：第一次尝试失败，但在以后的轮次中成功

　　SLEEP[x]：成功获取前sleeping次数

　　WAIT_TIME：花费在等待latch的时间

V$LATCH中的连接列

Column　　View　　　　Joined Column(s)

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

NAME/LATCH# 　　V$LATCH_CHILDREN 　　  NAME/LATCH#

NAME 　　　　　　V$LATCHHOLDER 　　　　NAME

NAME/LATCH# 　　V$LATCHNAME 　　　　     NAME/LATCH#

NAME 　　　　　　V$LATCH_MISSES　　        PARENT_NAME

示例：

下列的示例中，创建一个表存储查询自v$latch的数据：

CREATE TABLE snap_latch as SELECT 0 snap_id, sysdate snap_date, a.* FROM V$LATCH a;
ALTER TABLE snap_latch add  (constraint snap_filestat primary key (snap_id, name)); 

最初，snap_id被置为0，稍后，snap_latch表的snap_id列被更新为1：

INSERT INTO snap_latch SELECT 1, sysdate, a.* FROM V$LATCH a;

注意你通过sql语句插入记录时必须增加snap_id的值。

在你连续插入记录之后，使用下列的select语句列出统计。注意0不能成为被除数。

SELECT SUBSTR(a.name,1,20) NAME, (a.gets-b.gets)/1000 "Gets(K)",
       (a.gets-b.gets)/(86400*(a.snap_date-b.snap_date)) "Get/s",
       DECODE ((a.gets-b.gets), 0, 0, (100*(a.misses-b.misses)/(a.gets-b.gets))) MISS,
       DECODE ((a.misses-b.misses), 0, 0,
              (100*(a.spin_gets-b.spin_gets)/(a.misses-b.misses))) SPIN,
       (a.immediate_gets-b.immediate_gets)/1000 "Iget(K)",
       (a.immediate_gets-b.immediate_gets)/ (86400*(a.snap_date-b.snap_date)) "IGet/s",
       DECODE ((a.immediate_gets-b.immediate_gets), 0, 0,
       (100*(a.immediate_misses-b.immediate_misses)/ (a.immediate_gets-b.immediate_gets)))
IMISS
  FROM snap_latch a, snap_latch b
 WHERE a.name = b.name
   AND a.snap_id = b.snap_id + 1
   AND ( (a.misses-b.misses) > 0.001*(a.gets-b.gets)
       or (a.immediate_misses-b.immediate_misses) >
       0.001*(a.immediate_gets-b.immediate_gets))
ORDER BY 2 DESC;

下例列出latch统计项，miss列小于0.1%的记录已经被过滤。

什么时候需要检查latch统计呢？看下列项：

　　misses/gets的比率是多少

　　获自spinning的misses的百分比是多少

　　latch请求了多少次

　　latch休眠了多少次

Redo copy latch看起来有很高的的失误率，高达92.3%。不过，我们再仔细看的话，Redo copy latches是获自immediate模式。

immediate模式的数值看起来还不错，并且immediate模式只有个别数大于willing to wait模式。所以Redo copy latch其实并不存在竞争。

不过，看起来shared pool和library cache latches可能存在竞争。考虑执行一条查询检查latches的sleeps以确认是否确实存在问题。

latch有40余种，但作为DBA关心的主要应有以下几种：

　　Cache buffers chains latch：当用户进程搜索SGA寻找database cache buffers时需要使用此latch。

　　Cache buffers LRU chain latch：当用户进程要搜索buffer cache中包括所有 dirty blocks的LRU (least recently used) 链时使用该种latch。

　　Redo log buffer latch：这种latch控制redo log buffer中每条redo entries的空间分配。

　　Row cache objects latch：当用户进程访问缓存的数据字典数值时，将使用Row cache objects latch。

Latches调优

不要调整latches。如果你发现latch存在竞争，它可能是部分SGA资源使用反常的征兆。要修正问题所在，你更多的是去检查那部分SGA资源使用的竞争情况。仅仅从v$latch是无法定位问题所在的。

关于latches的更多信息可以浏览Oracle Database Concepts。

v$latch_children

数据库中有些类别的latches拥有多个。V$LATCH中提供了每个类别的总计信息。如果想看到单个latch，你可以通过查询本视图。

例如：

select name,count(*) ct from v$Latch_children group by name order by ct desc;

与v$latch相比，除多child#列外，其余列与之同，不详述~~

v$lock

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

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

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

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

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

select * from v$lock where sid=143

V$LOCK中的常用列

1. SID：表示持有锁的会话信息。
2. TYPE：表示锁的类型。值包括TM和TX等。
3. LMODE：表示会话等待的锁模式的信息。用数字0－6表示，和表1相对应。
4. 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：用户定义锁

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

V$LOCK中的连接列

Column　　View　　　　Joined Column(s)

SID 　　V$SESSION　　　　　　 SID

ID1, ID2, TYPE 　　V$LOCK 　　ID1, ID2, TYPE

ID1 　　　　DBA_OBJECTS 　　　　OBJECT_ID

TRUNCID1/65536) 　　　　V$ROLLNAME USN

如果session在等待锁，这可被用于找出session持有的锁，。

可被用于找出DML锁类型的被锁对象(type='TM')

可被用于找出行级事务锁(TYPE='TX')使用中的回滚段，不过，需要通过V$TRANSACTION连接查询得到。

表1 Oracle的TM锁类型
锁模式	锁描述	解释	SQL操作
0	none
1	NULL	空	Select
2	SS(Row-S)	行级共享锁，其他对象只能查询这些数据行	Select for update、Lock for update、Lock row share
3	SX(Row-X)	行级排它锁，在提交前不允许做DML操作	Insert、Update、Delete、Lock row share
4	S(Share)	共享锁	Create index、Lock share
5	SSX(S/Row-X)	共享行级排它锁	Lock share row exclusive
6	X(Exclusive)	排它锁	Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

数字越大锁级别越高, 影响的操作越多。一般的查询语句如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的锁。

　　如果出现了锁的问题, 某个DML操作可能等待很久没有反应。当你采用的是直接连接数据库的方式，也不要用OS系统命令 $kill process_num 或者

　　$kill -9 process_num来终止用户连接，因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。

示例：

我按照自己的理解演示的TX,TM锁如下：

1.create table TMP1(col1  VARCHAR2(50));--创建临时表

2.select * from v$lock;--关掉当前锁信息

3.select * from tmp1 for update; --加锁

4.select * from v$lock;   ---看看现在的锁列表，是不是多了两条记录。Type分别为tx,tm，对照表1。

5.新开一个连接，然后

select * from tmp1 for update;  --呵呵，等待状态了吧

select * from v$lock;  --又新增了两条记录，其它一条type=tx,lmode=0

查看当前被锁的session正在执行的sql语句

select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ a.username, a.machine, a.sid, a.serial#, a.last_call_et "Seconds", b.id1, c.sql_text "SQL"
from v$session a, v$lock b, v$sqltext c
where a.username is not null and a.lockwait = b.kaddr and c.hash_value =a.sql_hash_value

将之前的for update语句commit或者rollback，然后新开连接的session拥有锁。有兴趣的朋友还可以试试两条for update的时候，关闭先执行的那个窗口，看看oracle会给出什么样的响应。

Oracle数据库中的锁机制研究

http://soft.zdnet.com.cn/software_zone/2007/0208/377403.shtml

DB2和 Oracle的并发控制（锁）比较

http://www.ibm.com/developerworks/cn/db2/library/techarticles/dm-0512niuxzh/

Itpub论坛的oracle专题深入讨论区也有一篇非常精彩的讨论，地址如下：

我对ORACLE数据锁的一点体会

http://www.itpub.net/270059.html

v$locked_object

本视图列出系统上的每个事务处理所获得的所有锁。

V$LOCKED_OBJECT中的列说明：

1. XIDUSN：回滚段号
2. XIDSLOT：槽号
3. XIDSQN：序列号
4. OBJECT_ID：被锁对象ID
5. SESSION_ID：持有锁的sessionID
6. ORACLE_USERNAME：持有锁的Oracle 用户名
7. OS_USER_NAME：持有锁的操作系统 用户名
8. PROCESS：操作系统进程号
9. LOCKED_MODE：锁模式，值同上表1

示例：

1.以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;

select sess.sid,
   sess.serial#,
   lo.oracle_username,
   lo.os_user_name,
   ao.object_name,
   lo.locked_mode
   from v$locked_object lo,
   dba_objects ao,
   v$session sess
where ao.object_id = lo.object_id and lo.session_id = sess.sid
--详见锁.doc
 select username,
       v$lock.sid,
       trunc(id1/power(2,16)) rbs,
       bitand(id1,to_number('ffff','xxxx'))+0 slot,
       id2 seq,
       lmode,
       request
from v$lock, v$session
where v$lock.type = 'TX'
  and v$lock.sid = v$session.sid
and v$session.username = USER;
prompt update emp set ename = upper(ename);;
prompt update dept set deptno = deptno-10;;
SCOTT    133    7    23    564    0    6
SCOTT    133    3    2    651    6    0
SCOTT    143    7    23    564    6    0

Lmode为6是一个排他锁，request为0 你拥有这个锁，request为6就表示该会话正在请求锁，

如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁：

alter system kill session 'sid,serial#';