BlogJava-村東頭-随笔分类-DataBase

Oracle锁机制锁问题的详细分析

東頭bing阿頭 — Fri, 07 Nov 2008 07:40:00 GMT

在任何多用户数据库应用中,最终必然会出现两个用户希望同时处理相同记录的情况.这种情况在逻辑上是不可能的,并且数据库必须确保其在物理上也是不可能的.事务隔离性原则要求数据库保证:在 ,这个会话无法影响另一个会话,并且后者也无法看到前者.为了实现这个要求,数据库创行话并发的数据访问,甚至在多个会话请求访问相同的记录时,数据库也必须确保这些会话排队依次进行.
借助于记录和表锁定机制,我们可以实现并发的串行化.oracle数据库中的锁定是完全自动的.一般而言,只有在试图结合软件与自动锁定机制是或者编程人员编写的代码太糟糕时才会引发某些问题.

共享锁与排他锁

Oracle数据库中锁定的标准级别保证了最大可能的并发级别也就是说,如果某个会话正在更新一条记录,那么只有这条记录会被锁定.此外,锁定这条记录是为了防止其他会话对其进行更新,其他会话可以随时执行读取操作.只有在使用commit或rollback命令结束事务之后,锁定才会被解除.这种锁定是一个”排他锁”:在指定记录上请求排他锁的第一个会话会得到这个锁定,其他请求对该记录进行写访问的会话则必须等待.虽然这条记录已通过锁定会话进行了更新,但是对其进行读访问你是被允许的(而且经常会出现这种情况),并且这些读操作会涉及撤销数据的使用,从而确保都会回并不会看到任何未被提交的变化对于一条记录或一个完整表上的一个排他锁来说,每次只能有一个会话可以获得这个排他锁,不过许多会话可以同时获得相同对象上的”共享锁”.在一条记录上设置共享锁毫无意义,其原因在于锁定一条记录的唯一目的就是不允许其他会话更改它.共享锁被置于整个表上,同时许多会话可以获得同一个表上的共享锁.在一个表上放置共享锁的目的是为了防止另一个会话获得这个表上的排他锁(在已存在共享锁的情况下无法再获得排他锁).在表上防止排他锁是需要执行DDL语句.如果其他任何会话已经在一个表上放置了共享锁,那么我们就无法执行修改某个对象的语句(例如删除这个表的某一列).
为了在记录上执行DML语句,当前会话必须获取待更新记录上的排他锁以及包含这些记录的表上的共享锁.如果另一个会话已经获取了待更新记录上的排他锁,那么当前会话将被挂起,直至使用COMMIT或ROLLBACK命令解除这些锁定,如果另一个会话已经获取了待修改记录的表上的共享锁以及其他记录上的排他锁,那么就不存在任何问题.一个表上的排他锁会锁定这个表,但是,如果不需要执行DDL语句,那么我们就可以不锁定整个表的默认锁定机制.

提示:只有在特别请求并且编程人员具有充分理由的情况下,才可以要求在整个表上放置排他锁.

DML锁与DDL锁
所有DML语句都至少需要两种锁定:受影响记录上的排他锁,以及包含受影响记录的表上的共享锁.排他锁能够防止其他会话干预指定的记录,而共享锁则能够阻止其他会话使用DDL语句修改表的定义.这两种锁定会被自动请求.如果某条DML语句在指定记录上无法获取所需的排他锁,那么这条语句会被挂起直至获得所需的排他锁.
执行DDL命令需要使用所涉及对象上的排他锁.只有在针对指定表的所有DML事务结束,并且记录上的排他锁以及表上的共享锁都被解除之后,我们才可以获得执行DDL命令所需的排他锁,任何DDL语句所需的排他锁都是被自动请求的.但是,如果无法获取所需的排他锁(通常是因为其他会话已经获得用于DML语句的共享锁),那么DDL语句就会由于错误立即终止.

例子:
1.       使用SQL*PLUS,作为用户SYSTEM连接数据库.
2.       创建一个表,并且在这个表中插入一条记录.
>create table t1(c1 number);
       >insert into t1 values(1);
       >commit;
3.再次使用SQL*PLUS并作为用户SYSTEM进行连接,从而打开另一个会话.
4.在第一个会话中执行一个DML命令,这个命令会在插入的记录上放置一个排他锁,同时还会在创建的表上放置一个共享锁.
   >update table t1 set c1=2 where c1=1;
5.如下所示,在第二个会话中执行第一条针对新建表的DDL语句.
   >alter table t1 add(c2 date);
   error at line 1:
ora-00054:resource busy and acquire with nowait specified
因为DDL语句需要表上的排他锁,而这与DML语句已在表上放置了共享锁相冲突,所以试图在表中插入一个列的这条DDL语句会失败.需要注意的是:在类似情况下,DML语句会等待并不断进行尝试,直至获得其所需的锁(换句话说就是挂起);而DDL语句则会由于错误立即终止.
       6.在第一个会话中,提交当前事务
          >commit;
       7.在第二个会话中,重新执行步骤5.此时,因为不纯在与DDL排他锁相冲突的DML共享锁,因此DDL语句将成功的执行.
       8.在第一个会话中 ,锁定整个表.
        >lock table t1 in exclusive mode;
       9.在第二个会话中,插入一条记录.此时,这个会话将被挂起.
        >insert into t1 values (1,sysdate);
       10.在第一个会话中,通过执行COMMIT命令解除整个表上的锁定.需要注意的是,ROLLBACK命令也可以实现相同的目的.
        >commit;
       11.第二个会话会释放并且现在会完成插入操作.随后,执行COMMIT命令,终止当前事务斌且解除该记录上的排他锁.

关于如何解决死锁的问题.
１.查哪个过程被锁
查V$DB_OBJECT_CACHE视图:
SELECT * FROM V$DB_OBJECT_CACHE WHERE OWNER=''过程的所属用户'' AND LOCKS!=''0'';

2. 查是哪一个SID,通过SID可知道是哪个SESSION.
查V$ACCESS视图:
SELECT * FROM V$ACCESS WHERE OWNER=''过程的所属用户'' AND NAME=''刚才查到的过程名

版权归原作者和各发布网站所有，此文章仅供学习参考之用

東頭bing阿頭 2008-11-07 15:40 发表评论

锁等待的诊断及排除

東頭bing阿頭 — Fri, 07 Nov 2008 06:32:00 GMT

在ORACLE中，为了保证数据的一致性，在对数据库中的数据进行操作时，系统会进行对数据相应的锁定。
当程序对所做的修改进行提交(commit)或回滚后(rollback)后，锁住的资源便会得到释放，从而允许其它用户进行操作。
但是，有时，由于程序中的原因，锁住资源后长时间未对其工作进行提交；或是由于用户的原因，如调出需要修改的数据后，未及时修改并提交，而是放置于一旁；或是由于客户服务器方式中客户端出现"死机"，而服务器端却并未检测到，从而造成锁定的资源未被及时释放，影响到其它用户的操作。
这时，我们需要迅速地诊断出锁住资源的用户并解决其锁定。

1. 诊断系统中的锁
为了找出系统中那些用户锁住资源以及那些用户在等待相应的资源，可使用以下语句(其中的/*+ NO_MERGE(..) */千万不可省略, 否则会很慢)：

-- looklock.sql
-- use the NO_MERGE hints can speed up the query
select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ 'Wait' "Status", 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
union
select /*+ NO_MERGE(a) NO_MERGE(b) NO_MERGE(c) */ 'Lock' "Status", 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 b.id1 in
(select /*+ NO_MERGE(d) NO_MERGE(e) */ distinct e.id1
from v$session d, v$lock e
where d.lockwait = e.kaddr)
and a.username is not null
and a.sid = b.sid
and b.request=0
and c.hash_value =a.sql_hash_value;

执行后的结果如下所示：
Stat USERNAME MACHINE SID SERIAL# Seconds ID1
---- ------------------------------ ---------------- --------- --------- --------- ---------
SQL
----------------------------------------------------------------
Lock CIQUSR CIQ\DULMACER 12 966 245 131089
select * from c_trade_mode for update

Wait CIQUSR CIQ\DULMACER 10 735 111 131089
update c_trade_mode set x_name = 'zzz' where x_code='5'

Wait CIQUSR CIQ\DULMACER 15 106 1094 131089
select * from c_trade_mode for update

其中：
Status有两种状态，LOCK表明该进程锁住了某个资源，WAIT表示该进程正在等待某个资源。
Username, Machine分别为ORACLE用户名及机器名
SID，SERIAL#可用于随后的解锁操作
Seconds表示该进程最后一次进行操作至当前的时间(秒)
ID1, 锁标识。某个LOCK状态的ID1与某个WAIT状态的ID1相同，可说明锁的正是另一个进程等待的。
SQL: 锁住资源的SQL语句

2. 解除锁

诊断出锁的状态后，若发现该阻塞其它用户进程的进程是正常操作中，则可通知该用户对其进行提交，从而达到释放锁资源的目的；若为非正常操作，即，其状态为"inactive"，且其Seconds已为较多长时间，则可执行以下语句将该进程进行清除，系统会自动对其进行回滚，从而释放锁住的资源。

alter system kill session 'sid, serial#';

例如: 对于上例中显示的结果, 可用以下语句清除锁住资源的进程:
alter system kill session '12, 966';

关于你所说：在网络断掉（通过拔掉网线）或非正常终止进程（通过task manager强行关闭sql*plus)时，oracle在有限的时间内（我只观查了5-10分）内，oracle未能对该进程作任何处理。
这个处理与TCP协议有关，因为SQL NET在使用TCP/IP协议进行网络连接时是一种短连接,当ORACLE连接异常终止时，因为是异常终止，终止信号并没有通过网络通知server端，因此只有下次server有结果从服务器端返回需与client通信时，server才会发现此client已经端掉。因此出现你前面所提ORACLE处理异常终止进程延时情况.
死锁：你可以试验一条彼此存在依赖关系的update语句，ORACLE处理这种锁时不是很好。

查锁语句：查询产生锁的用户锁sql
select a.username username, a.sid sid, a.serial# serial,b.id1 id1, c.sql_text sqltext
from v$session a, v$lock b, v$sqltext c
where b.id1 in
　　 (select distinct e.id1
　　 from v$session d, v$lock e
　　 where d.lockwait = e.kaddr)
　　 and a.sid = b.sid
　　 and c.hash_value = a.sql_hash_value
　　 and b.request = 0;

死锁：当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就出现死锁。
如事务1在表A行记录#3中有一排它锁，并等待事务2在表A中记录#4 中排它锁的释放，而事务2在表A记录行#4中有一排它锁，并等待事务 1在表A中记录#3中排它锁的释放，事务1与事务2彼此等待，因此就造成了死锁。死锁一般是因拙劣的事务设计而产生

版权归原作者和各发布网站所有，此文章仅供学习参考之用

東頭bing阿頭 2008-11-07 14:32 发表评论

数据库锁表原因分析<二>

東頭bing阿頭 — Fri, 07 Nov 2008 03:34:00 GMT

比如有两个用户一个userA,一个userB
当userA发出 select * from 表名 for update of 字段时
这是纪录被锁住等待更新
当userB此时也发出select * from 表名 for update of 字段时
并且for update of 的纪录已经被userA锁定
这是userB只能等待userA提交后才能获取到userA被占用的纪录
如果userA不提交userB就会无限期的等待
解决方法
userB执行select * from 表名 for update of 字段 no wait 10;
这时虽然纪录被userA锁定但是userB会等待10秒如果10秒内userA释放
了纪录，则userB获取该锁,如果10秒后userA未释放锁,则userB返回
错误消息
ora-30006:资源已被占用;执行此操作时出现wait超时

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

userA锁住一条纪录
userB锁住一条纪录
userA请求锁住userB正在锁住的纪录
而同时userB请求锁住userA正在锁住的纪录
这时候就会产生死锁

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

如果在事务中执行了一条不满足条件的update语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁。

版权归原作者和各发布网站所有，此文章仅供学习参考之用

東頭bing阿頭 2008-11-07 11:34 发表评论

数据库锁表原因分析<一>

東頭bing阿頭 — Thu, 06 Nov 2008 10:11:00 GMT

在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性，目前大部分RDBMS都采用加锁技术。然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术，最小化死锁是开发联机事务处理系统的关键。
死锁产生的原因
    在联机事务处理系统中，造成死机主要有两方面原因。一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状态，从而造成其对资源需求的死锁。
    另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中，最小锁为2K一页的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)，被访问的频率高，就容易在该页上产生死锁。

容易发生死锁的几种情况如下:
1>不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表;
2>在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non-clustered);
3>表中的记录少，且单条记录较短，被访问的频率较高；
4>整张表被访问的频率高(如代码对照表的查询等)。

以上死锁情况的对应处理方法如下:
1>在系统实现时应规定所有存储过程、触发器、动态SQL语句段中，对多张表的操作总是使用同一顺序。如：有两个存储过程proc1、proc2，都需要访问三张表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的顺序进行访问，那么，proc2也应该按照以上顺序访问这三张表。
2>对在交换期间添加记录频繁的表，使用群集索引(clustered)，以减少多个用户添加记录到该表的最后一页上，在表尾产生热点，造成死锁。这类表多为往来账的流水表，其特点是在交换期间需要在表尾追加大量的记录，并且对已添加的记录不做或较少做删除操作。
3>对单张表中记录数不太多，且在交换期间select或updata较频繁的表可使用设置每页最大行的办法，减少数据在表中存放的密度，模拟行级锁，减少在该表上死锁情况的发生。这类表多为信息繁杂且记录条数少的表。

如：系统配置表或系统参数表。在定义该表时添加如下语句：
with   max_rows_per_page=1
在存储过程、触发器、动态SQL语句段中，若对某些整张表select操作较频繁，则可能在该表上与其他访问该表的用户产生死锁。对于检查账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at isolation read uncommitted子句的方法解决。该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表操作的并发性。在系统高负荷运行时，该方法的效果尤为显著。
如：
select * from titles at isolation read uncommitted
对流水号一类的顺序数生成器字段，可以先执行updata流水号字段+1，然后再执行select获取流水号的方法进行操作。

版权归原作者和各发布网站所有，此文章仅供学习参考之用

東頭bing阿頭 2008-11-06 18:11 发表评论