bluetears 2019-06-27
oracle中分为两种模式的锁,一种是排他锁(X锁),另一种是共享所(S锁).
锁是实现并发的主要手段,在数据库中应用频繁,但很多都由数据库自动管理,当事务提交后会自动释放锁.
这里主要介绍下常用的DML锁,它主要保证了并发访问时数据的完整性.它又可以分为以下两种类型的锁:
1) 行级锁(TX),也可以称为事务锁.当修改表中某行记录时,需要对将要修改的记录加行级锁,防止两个事务同时修改相同记录,事务结束,该锁也会释放,是粒度最细的锁.该锁只能属于排他锁(X锁).
2) 表级锁(TM),主要作用书防止在修改表的数据时,表的结构发生变化.例如,会话S在修改表A的数据时,它会得到表A的TM锁,而此时将不允许其他会话对该表进行变更或删除操作. 该情况的验证过程如下:
UPDATE TABLE_NAME SET COLUMN= 'test' WHERE ID = 'id';
此时已经锁定该表,表级锁将不允许在事务结束前其他会话对表TABLE_NAME进行DDL操作.
其次,在执行DROP TABLE TABLE_NAME
操作,执行后会提示ORA-00054错误.
原因是:
在执行DML操作时,数据库会先申请数据对象上的共享锁,防止其他会话对该对象执行DDL操作。一旦申请成功,则会对将要修改的记录申请排他锁,如果此时其他会话正在修改该记录,那么等待其事务结束后再为修改的记录加上排他锁。
下表列出了以上5中模式相互之间的兼容关系.其中,✔表示相互兼容,×表示相互不兼容
\ | RS | S | RX | SRX | X | |
---|---|---|---|---|---|---|
RS | ✔ | ✔ | ✔ | ✔ | × | |
S | ✔ | ✔ | × | × | × | |
RX | ✔ | × | ✔ | ✔ | × | |
SRX | ✔ | × | × | × | × | |
X | × | × | × | × | × |
下面所示是Oracle中的各种SQL语句所产生的表级锁模式以及允许的锁定模式情况的汇总.
SQL语句 | 表锁模式 | RS | S | RX | SRX | X |
---|---|---|---|---|---|---|
SELECT ...FROM table | NONE | Y | Y | Y | Y | Y |
INSERT INTO ... | RX | Y | N | Y | N | N |
UPDATE table ... | RX | Y | N | Y | N | N |
DELETE FROM table ... | RX | Y | N | Y | N | N |
SELECT * FROM table FOR UPDATE | RX | Y | N | Y | N | N |
LOCK TABLE table IN ROW SHARE MODE | RS | Y | Y | Y | Y | N |
LOCK TABLE table IN ROW EXCLUSIVE MODE | RX | Y | N | Y | N | N |
LOCK TABLE table IN SHARE MODE | S | Y | N | N | N | N |
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE | SRX | Y | N | N | N | N |
LOCK TABLE table IN EXCLUSIVE MODE | X | N | N | N | N | N |
在Oracle中除了执行DML时自动为表添加TM锁外,也可以主动地为表添加TM锁,语法如下:
LOCK TABLE [schema.] table IN [EXCLUSIVE] [SHARE] [ROW EXCLUSIVE] [SHARE ROW EXCLUSIVE] [ROW SHARE* | SHARE UPDATE*] MODE [NOWAIT]
DDL锁也可以称为数据字典锁,主要作用是保护模式中对象的结构.当执行DDL操作时首先Oracle会自动地隐式提交一次事务,然后自动地给处理对象加上锁;当DDL结束时,Oracle会隐式地提交事务并释放DDL锁.与DML不同的是,用户不能显式的要求使用DDL锁.
DDL锁分为如下3类:
例如当一个会话修改表A的记录时,它会对该记录加锁,而此时如果另一个会话也来修改此记录,那么第二个会话将因得不到排他锁而一直等待,此时会出现执行SQL时数据库长时间没有响应的现象.直到第一个会话把事务提交,释放锁,第二个会话才能对数据进行操作.
下面为大家示例锁等待现象:
UPDATE PRODUCTINFO SET ORIGIN = '修改1' WHERE PRODUCTID = 1;
此时虽然提示已更新,但事务并没有提交.接下来进行第二步操作.
UPDATE PRODUCTINFO SET ORIGIN = '修改2' WHERE PRODUCTID = 1;
此时执行效果不会提示已更新,而是一直等待.
此时的情况是因为第一个会话封锁了该记录,但事务没有结束,锁不会释放,而这时第二个会话也要修改同一条记录,但它缺没有办法获得排他锁,所以只能等待.如果第一个会话修改数据的事务结束,那么第二个会话会结束等待.及时地结束事务是解决锁等待情况发生的有效方法.
死锁的发生和锁等待不同,它是锁等待的一个特例,通常发生在两个或者多个会话之间.假设一个会话想要修改两个资源对象,可以是表也可以是字段,修改这两个资源的操作在一个事务当中,当它修改第一个对象时需要对其锁定,然后等待第二个对象,这时如果另外一个会话也需要修改这两个资源对象,并且已经获得对第二个对象的锁定,那么就会出现死锁,因为当前会话锁定了第一个对象等待第二个对象,而另一个会话锁定了第二个对象等待第一个对象.这样,两个会话都不能得到想要得到的对象,于是出现死锁.
这里例子就不在展示,大家可以自行试一试.实际开发中出现死锁情况大致有以下几种原因: