oracle锁

ORACLE锁

设立封锁机制主要是为了对并发操作进行控制，对干扰进行封锁，保证数据的一致性和准确性。Oracle数据库封锁方式有三种：共享锁，独占锁，共享更新锁

锁类型

Oracle　RDBMS的封锁类型可分为如下三类：

１、内部级封锁

内部级封锁是用于保护ORACLE内部结构，由系统内部实现，用户不能访问，因此我们不必对此做过多的了解。

２、DDL级封锁（字典/语法分析封锁）

DDL级封锁也是由ORACLE　RDBMS来控制，它用于保护数据字典和数据定义改变时的一致性和完整性。它是系统在对SQL定义语句作语法分析时自动地加锁，无需用户干予。字典/语法分析封锁共分三类：

（１）、字典操作锁：用于对字典操作时，锁住数据字典，此封锁是独占的，从而保护任何一个时刻仅能对一个字典操作。

（２）、字典定义锁：用于防止在进行字典操作时又进行语法分析，这样可以避免在查询字典的同时改动某个表的结构。

（３）、表定义锁：用于　一个SQL语句正当访问某个表时，防止字典中与该表有关的项目被修改。

３、DML级封锁

DML级封锁用于控制并发事务中的数据操纵，保证数据的一致性和完整性，其封锁对象可以是表或行。

对用户的数据操纵，Oracle可以自动为操纵的数据进行封锁，但如果有操纵授权，则为满足并发操纵的需要另外实施封锁。DML封锁可由一个用户进程以显式的方式加锁，也可通过某些　　 SQL语句隐含方式实现。

DML锁有如下三种封锁方式：

（1）、共享封锁方式（SHARE）

（2）、独占封锁方式（EXCLUSIVE）

（3）、共享更新封锁（SHARE UPDATE）

其中SHARE，EXCLUSIVE用于表封锁，SHARE UPDATE用于行封锁。

1、共享方式的表封锁

共享方式的表封锁是对表中的所有数据进行封锁，该锁用于保护查询数据的一致性，防止其它用户对已封锁的表进行更更新。其它用户只能对该表再施加共享方式的锁，而不能再对该表施加独占方式的封锁，共享更新锁可以再施加，但不允许持有共享更新封锁的进程做更新。共享该表的所有用户只能查询表中的数据，但不能更新。共享方式的表封锁只能由用户用SQL语句来设置，基语句格式如下：

LOCK TABLE <表名>[,<表名>]...

IN SHARE MODE [NOWAIT]

执行该语句，对一个或多个表施加共享方式的表封锁。当指定了选择项NOWAIT，若该封锁暂时不能施加成功，则返回并由用户决定是进行等待，还是先去执行别的语句。

持有共享锁的事务，在出现如下之一的条件时，便释放其共享锁：

A、执行COMMIT或ROLLBACK语句。

B、退出数据库（LOG　OFF）。

C、程序停止运行。

共享方式表封锁常用于一致性查询过程，即在查询数据期间表中的数据不发生改变。

2、独占方式表封锁

独占方式表封锁是用于封锁表中的所有数据，拥有该独占方式表封锁的用户，即可以查询该表，又可以更新该表，其它的用户不能再对该表施加任何封锁（包括共享、独占或共享更新封锁）。其它用户虽然不能更新该表，但可以查询该表。

独占方式的表封锁可通过如下的SQL语句来显示地获得：

LOCK TABLE <表名>[,<表名>]....

IN EXCLUSIVE MODE [NOWAIT]

独占方式的表封锁也可以在用户执行DML语句INSERT、UPDATE、DELETE时隐含获得。

拥有独占方式表封锁的事务，在出现如下条件之一时，便释放该封锁：

（1）、执行COMMIT或ROLLBACK语句。

（2）、退出数据库（LOG OFF）

（3）、程序停止运行。

独占方式封锁通常用于更新数据，当某个更新事务涉及多个表时，可减少发生死锁。

3、共享更新封锁方式

共享更新封锁是对一个表的一行或多行进行封锁，因而也称作行级封锁。表级封锁虽然保证了数据的一致性，但却减弱了操作数据的并行性。行级封锁确保在用户取得被更新的行到该行进行更新这段时间内不被其它用户所修改。因而行级锁即可保证数据的一致性又能提高数据操作的迸发性。

可通过如下的两种方式来获得行级封锁：

（1）、执行如下的SQL封锁语句，以显示的方式获得：

LOCK TABLE <表名>[,<表名>]....

IN SHARE UPDATE　MODE [NOWAIT]

（2）、用如下的SELECT ...FOR UPDATE语句获得：

SELECT <列名>[,<列名>]...

FROM <表名>

WHERE <条件>

FOR UPDATE OF <列名>[,<列名>].....[NOWAIT]

一旦用户对某个行施加了行级封锁，则该用户可以查询也可以更新被封锁的数据行，其它用户只能查询但不能更新被封锁的数据行．如果其它用户想更新该表中的数据行，则也必须对该表施加行级锁．即使多个用户对一个表均使用了共享更新，但也不允许两个事务同时对一个表进行更新，真正对表进行更新时，是以独占方式封锁表，一直到提交或复原该事务为止。行锁永远是独占方式锁。

当出现如下之一的条件，便释放共享更新锁：

（１）、执行提交（COMMIT）语句；

（２）、退出数据库（LOG　OFF）

（３）、程序停止运行。

执行ROLLBACK操作不能释放行锁。

从上面讲述可见，ORACLE　RDBMS的加锁机制，解决了并发事务的相容与互斥问题。相容保证事务的并发性，互斥确保数据的一致性。

我们来看一个选择题：（综合考虑以上所谈的锁）

User SCOTT executes the following command on the EMP table but has not issued COMMIT, ROLLBACK,

or any data definition language (DDL) command:

SQL> SELECT job FROM emp

2 WHERE job='CLERK' FOR UPDATE OF empno;

SCOTT has opened another session to work with the database. Which three operations would wait when

issued in SCOTT's second session? (Choose three.)

A) LOCK TABLE emp IN SHARE MODE;

B) LOCK TABLE emp IN EXCLUSIVE MODE;

C) DELETE FROM emp WHERE job='MANAGER';

D) INSERT INTO emp(empno,ename) VALUES (1289,'Dick') ;

E) SELECT job FROM emp WHERE job='CLERK' FOR UPDATE OF empno;

（A,B,E)

解释： 当SCOTT在SESSION1中获得了行上的所SX，SCOTT在SESSION2中执行E选项是很明显是不能获得行上的SX ，对于A 选项，因为要获得表级共享锁，就是要获得对EMP表每一行的共享锁，因为有一行在SESSION1中已经被获得部分行独占锁，所以不能在SESSION2中获得该行的任何锁，那么就不能获得表EMP上的表共享锁，那么B 选现就不用在说了，和A 选项同理。对于 C 和 D 选项，因为他们要在别的行上的独占锁，和SESSION1 上行的独占锁没有冲突是可以的获得的，不需要WAIT 。

死锁 :

封锁虽然能够有效的解决并发操作，但是任何资源的独占都会有死锁的危险。例如：有两个事务T1，T2，T1对数据A施加独占封锁，T2对数据B施加了独占封锁。再假设T1要对数据B加锁，由于B已被T2 独占封锁，因此T1置于等待状态，等待B被释放；现在若T2也要对A进行封锁，由于A已被T1独占封锁，因此T2也被置于等待状态。这样就形成了两个事务相互等待的状态，而且永远不能结束，此种情况称为死锁。

在Oracle系统中能自动发现死锁，并选择代价最小的，即完成工作量最少的事务予以撤消，释放该事务所拥有的全部锁，记其它的事务继续工作下去。

从系统性能上考虑，应该尽可能减少资源竞争，增大吞吐量，因此用户在给并发操作加锁时，应注意以下几点：

１、对于UPDATE和DELETE操作，应只封锁要做改动的行，在完成修改后立即提交。

２、当多个事务正利用共享更新的方式进行更新，则不要使用共享封锁，而应采用共享更新封锁，这样其它用户就能使用行级锁，以增加并行性。

３、尽可能将对一个表的操作的并发事务施加共享更新锁，从而可提高并行性。

４、在应用负荷较高的期间，不宜对基础数据结构（表、索引、簇和视图）进行修改

ORACLE里锁有以下几种模式:

0：none

1：null 空

2：Row-S 行共享(RS)：共享表锁，sub share

3：Row-X 行独占(RX)：用于行的修改，sub exclusive

4：Share 共享锁(S)：阻止其他DML操作，share

5：S/Row-X 共享行独占(SRX)：阻止其他事务操作，share/sub exclusive

6：exclusive 独占(X)：独立访问使用，exclusive

数字越大锁级别越高, 影响的操作越多。

1级锁有：Select，有时会在v$locked_object出现。

2级锁有：Select for update,Lock For Update,Lock Row Share

select for update当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select for update操作。

3级锁有：Insert, Update, Delete, Lock Row Exclusive

没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。

4级锁有：Create Index, Lock Share

locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。

00054, 00000, "resource busy and acquire with NOWAIT specified"

// *Cause: Resource interested is busy.

// *Action: Retry if necessary.

5级锁有：Lock Share Row Exclusive

具体来讲有主外键约束时update / delete ... ; 可能会产生4,5的锁。

6级锁有：Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive

以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：

col owner for a12

col object_name for a16

select b.owner,b.object_name,l.session_id,l.locked_mode

from v$locked_object l, dba_objects b

where b.object_id=l.object_id

/

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进程并不能彻底清除锁的问题。

TX锁等待的分析

在介绍了有关地Oracle数据库锁的种类后，下面讨论如何有效地监控和解决锁等待现象，及在产生死锁时如何定位死锁的原因。

监控锁的相关视图 数据字典是Oracle数据库的重要组成部分，用户可以通过查询数据字典视图来获得数据库的信息。和锁相关的数据字典视图如表2所示。

TX锁等待的监控和解决在日常工作中，如果发现在执行某条SQL时数据库长时间没有响应，很可能是产生了TX锁等待的现象。为解决这个问题，首先应该找出持锁的事务，然后再进行相关的处理，如提交事务或强行中断事务。

死锁的监控和解决在数据库中，当两个或多个会话请求同一个资源时会产生死锁的现象。死锁的常见类型是行级锁死锁和页级锁死锁，Oracle数据库中一般使用行级锁。下面主要讨论行级锁的死锁现象。

当Oracle检测到死锁产生时，中断并回滚死锁相关语句的执行，报ORA-00060的错误并记录在数据库的日志文件alertSID.log中。同时在user_dump_dest下产生了一个跟踪文件，详细描述死锁的相关信息。

在日常工作中，如果发现在日志文件中记录了ora-00060的错误信息，则表明产生了死锁。这时需要找到对应的跟踪文件，根据跟踪文件的信息定位产生的原因。

如果查询结果表明，死锁是由于bitmap索引引起的，将IND_T_PRODUCT_HIS_STATE索引改为normal索引后，即可解决死锁的问题。