一直有个疑问，也一直没做试验，希望和大家一起讨论。。。

murkey

1=2的问题还是有研究的，我也去研究下

DINGNING239

学习到不少东西

jvkojvko

我只知道他还是要我点commit的

owlstudio

原帖由 晶晶小妹 于 2008-5-24 22:12 发表
第一点 ： ORACLE的确是扫描数据，找到要修改的数据后，再开始修改。从扫描开始到开始实施第一条修改这段时间中，数据不被保护，也没有数据需要保护。
我做如下一个实验。我先以全表扫描更新这个大表中的每一行，马上换到另一个会话，用ROWID更新同一行：
步1：先看看表有多少行：
sid=49 pid=18> select count(*) from test1;
  COUNT(*)
----------
    727232

步2：在49会话开始更新
sid=49 pid=18> update test1 set object_name=lower(object_name) where object_name='中国';

步3：马上换到43会话，更新ROWID='AAAC83AAEAAAD19AAh'的行，这一行上49会话中要更新的行中的一个：
sid=43 pid=19> update test1 set object_name=upper(object_name) where rowid='AAAC83AAEAAAD19AAh';
已更新 1 行。

步4： 回到49号会话看看，UPDATE被43号会话阻塞。
虽然43号会话中的更新比49号会话的更新晚，但是43号阻塞了49号，因为49号会话描述行的时间比较长。
也就是说，在49号会话找到要更新的数据前，它并不对行加锁。

我开始有点不相信，上机做了一下测试，果真是这样！

很是疑惑：  先提交的任务被后提交的任务给阻塞，这有点不符合数据库的原理啊！

         如果这样，后执行的短小的交易反而先完成，先提交的长点的交易反而要等后提交的交易完成了才能完成？

         这对有些应用的业务会不会有影响呢 ？

         请高手赐教！

Yong Huang

原帖由 owlstudio 于 2008-7-3 21:59 发表
很是疑惑：  先提交的任务被后提交的任务给阻塞，这有点不符合数据库的原理啊！

晶晶小妹 and your experiments can be used to modify our understanding of the transaction mechanism. That is, the starting time of the transaction is NOT the time you submit the DML, but the time Oracle needs to lock the first row in the table. Think of this SQL: insert into mytable select * from verybigtable where... You won't see the TX lock until the query part starts to return rows. If "select * from verybigtable where..." takes 10 minutes to find the first matching row, the time lag will be 10 minutes.

Yong Huang

[ 本帖最后由 Yong Huang 于 2009-7-15 12:49 编辑 ]

owlstudio

嗯，想明白了，就看谁先给行加TX锁了！