我对ORACLE数据锁的一点体会

sargentti

最初由 beijing3721 发布
[B]事务槽，最多同时6个事务[/B]

何出此言？

fikong2005

此贴的故事还没讲完，怎么就沉下去了？顶起来

pandzhi

學習學習

meshada

看了后受益匪浅哪

likinglife

学习了。。。

麦克阿色

好东西，学习中！

strawbingo

虽然是老贴，好东西

tom_111

LZ呢？故事结果呢？多粒度封锁机制的下篇呢？继续！

tyhj1982

原帖由 ZALBB 于 2004-9-28 11:09 发表
对你这句话：以后不管是其它DML操作或是DDL操作,在检查是否有锁冲突时,
就不需要逐行检查各记录的加锁情况了,而只需要检查表一级的加锁情况。

我看不明白：

1、你这段话中的：是否有锁冲突，是指行级锁，还是表级锁？
2、SESSION1对表A执行DML操作后，SESSION2也对A执行DML操作，
   那ORACLE要不要检查行的加锁情况？若要，是不是只检查到表一级的加锁
   情况？若是，那它如何得知那些记录被加X锁的情况？哪些记录可操作，
   哪些不可？

我是这样理解的，解决记录（数据冲突）的，是靠TX锁上记录的事务信息，
而非意向锁。

你可以测试：当你对记录做了UPDATE操作后，通过DUMP保存此记录的BLOCK块，
可立即看到该块已经记录了被修改记录的事务信息-ITL（这里不考虑日志延时），
此信息指明了事务及回滚段的信息，与TX锁上的ID1，ID2表示的信息是一致的。
这样，当再有第二个事务来修此记录时，可能就在此被卡住了。

事实上，单纯地使用此语句LOCK TABLE table_name IN ROW EXCLUSIVE MODE,
并不体现对哪些数据加了X锁。

因此，我理解这个时候对表加的意向锁为S锁，是为了避免ALTER ，DROP TABLE在
其上面的操作。

请继续指教。

同问，在表一级加了RS或者RX锁以后，后续的会话申请锁时，只知道该表上已经有RS锁或RX锁，怎么知道表上具体那些记录已经被锁定，那些记录没有被锁定呢？如何得知的？根据表上已经存在的RS、RX意向锁吗？
SESSION1对表A执行DML操作后，SESSION2也对A执行DML操作，但是两个session操作的是不同的记录，
   那ORACLE要不要检查行的加锁情况？若要，是不是只检查到表一级的加锁
   情况？若是，那它如何得知那些记录被加X锁的情况？哪些记录可操作，
   哪些不可？

Yong Huang

原帖由 tyhj1982 于 2009-12-15 23:49 发表

同问，在表一级加了RS或者RX锁以后，后续的会话申请锁时，只知道该表上已经有RS锁或RX锁，怎么知道表上具体那些记录已经被锁定，那些记录没有被锁定呢？如何得知的？根据表上已经存在的RS、RX意向锁吗？
SESSION1对表A执行DML操作后，SESSION2也对A执行DML操作，但是两个session操作的是不同的记录，
   那ORACLE要不要检查行的加锁情况？若要，是不是只检查到表一级的加锁
   情况？若是，那它如何得知那些记录被加X锁的情况？哪些记录可操作，
   哪些不可？

I suggest you open a new thread for discussion.

In short, each row has a lock byte. The value in it indicates whether this row is locked or not.

Yong Huang