ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 我对ORACLE数据锁的一点体会

我对ORACLE数据锁的一点体会

原创 Linux操作系统 作者:wangkxxe 时间:2009-06-26 14:48:10 0 删除 编辑
我对ORACLE数据锁的一点体会

该贴的部分内容是针对帖中带的附件(一位大侠关于锁的理解),提的理解/疑问,
大家在读此贴前,请先阅读该文。


先说说各类型的锁:共享锁,排它说,共享排它锁(对表定义共享,对表操作的记录排它)。

1、我对文章中意向锁的理解,就是:对表的记录进行操作之前,先对表定义(包括表结构、约束等)
   加了共享锁,这是为了避免对表的DDL操作。

   比如:当你往TAB1插入一条记录时,该表的一个字段COL8是允许为空的,插入这条记录的该字段
   的值是空的,此时,若不对该表定义加共享锁,则另外一SESSION对TAB1.COL8加非空约束,
   那该表结构修改就与插入的记录发生冲突了。所以,当执行DML操作是,必定对操作的表加DDL
   共享锁。

   这是我理解的意向锁。
   
2、文章中提及,记录行是无共享锁。我对此观点表示不同:当插入/修改子表时,对应的父表的主键
   记录应该被加共享锁,因为此时要保证父键的存在。经测试,当插入/修改/删除子表时,父表
   确实被加了SS锁,此时可以对父表的主键做插入动作,但不允许做修改/删除。这符合逻辑。因为
   插入操作并不影响主外键的关系。但删除/修改则可能。

   
3、SHARE VS ROW SHARE有什么区别?

   我猜想:ROW SHARE是(级别=2)对表加表定义共享锁,SHARE(级别=4)是对表定义及表“所有”的
   记录加共享锁。但这样就有问题:1、SELECT FOR UPDATE产生TM=2、对查询出来的记录产生TX=6的
   锁,那这样应该与:表“所有”的记录加共享锁 相冲突了?但实际并不是,实际上,当对表加SHARE
   锁时,还是可以对该表执行 SELECT FOR UPDATE,但却不可以执行DML操作!
   
   现我只能这样理解,虽然产生了TX=6 的事务锁,但实际上,还并没有真正修改记录。和真正的
   INSERT ,UPDATE, DELETE 操作还是有区别的。也就是:SELECT FOR UPDATE这个锁有点特别:
   对加了共享锁的记录,还可以SELECT FOR UPDATE,但若想执行DML语句,则不可以,因为该表的
   “所有” 记录都加了共享锁。
   
4、若照第3点的理解,那SRX就是对表加共享锁,对表的所有记录加排它锁。这是我的猜测,不知道
   在什么地方会使用上这种锁。

总结:查看了ORACLE的文档,其并不解释如何定义的各级别的锁,为什么会这样定义,理由、用途何
在?现在我想使用各类型锁,来对ORACLE锁的各级别定义说明:

0、无
1、NULL,可以某些情况下,如分布式数据库的查询会产生此锁。
2、SS,表结构共享锁
3、SX,表结构共享锁+被操作的记录的排它锁
4、S, 表结构共享锁+所有记录共享锁
5、SRX 表结构共享锁+所有记录排它锁
6、X   表结构排它锁+所有记录排它锁


其中 SELECT FOR UPDATE是比较特殊的一种情况:由于其不修改记录,所以对这些记录而言,
并未产生真正的排它锁,这与DML操作产生的排它锁相比,是有差别的,但由于不允许在这些记录“再”
加SELECT FOR UPDATE,所以,也不是纯粹的共享锁,我认为其是介于共享锁和排它锁之间的一种特殊
的情况,因此,ORACLE在对表加了S锁后,还允许对该表执行SELCT FOR UPDATE,但实际上,此时此语句
已经无意义了,因为加了S锁的表不允许DML操作,故,此语句于普通的SELECT 语句无差别。

请拍砖。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12801008/viewspace-607655/,如需转载,请注明出处,否则将追究法律责任。

下一篇: DB2板块精华帖
请登录后发表评论 登录
全部评论

注册时间:2009-02-25

  • 博文量
    68
  • 访问量
    93867