ORACLE的多版本与读一致性

  先来看看这段代码：
  while s in (select * from table1) loop
    insert into table1 values(s.field1,s.field2,s.field3,s.field4,s.field5);
  end loop;
  如果是SQL server的开发人员，看到这段代码，肯定会摇头：这段代码有问题，这样递归插入，会一直到表爆掉为止；而ORACLE开发人员，则不会有觉得这段代码有什么不对。
  这是为什么呢？原因就是两个数据库系统的处理机制不一样，假设表table1的内容如下：
  field1  field2  field3  field4  field5
  1       2       3       4       5
  那么SQL server会这样处理：找到table1的第一条记录，把这条记录插入到table1中，这时select * from table1这个查询的内容就变成了
  field1  field2  field3  field4  field5
  1       2       3       4       5
  1       2       3       4       5
  于是循环就移动指针，把第二条记录复制下来插入到table1中，于是select * from table1这个查询又增加了一条记录，于是继续复制...，就这样一直继续下去，直至表被撑满。
  而在ORACLE中，系统指向第一条记录时，会判断这条记录的版本，由于这个版本在查询select * from table1被提交前就存在，所以它会被复制插入，然后指针移向下一记录，也就是刚刚加入的这条，判断它的版本，发现它是在查询提交后生成的，这时ORACLE就会去找这条记录在查询被提交时的版本，得到的结果是当时没有这条记录，ORACLE就不认为它是查询结果中的记录，于是跳过，再去找下一条记录。
  从上面的处理过程可以看出，SQL server遇到这段代码，会不停循环下去--如果表的记录数不是限制的话，而ORACLE会把表的记录复制一次插入就推出。
  ORACLE对所有的数据都记录了它任何时间的状态，这样做当然会使数据占用更大的空间，但也使得查询得出的数据全部都是同一刻状态的数据。
  举个例子，如果对于一个银行的数据库系统，保存有储户的帐号和储蓄金额，假设在经理查询本行所有帐户的总储蓄额（假设数据量较大，需要花费的查询时间较长）时，有用户做了转帐处理，就可能出现以下情况：
  用户    金额
  A       1400
  B       2200
  C       600
  经理在使用sum统计总金额且没有使用锁定，如果已经统计完A和B的金额相加之后，统计到C之前，用户A将自己帐户上的金额转了1000到C的帐户上，那么对于某些数据库系统就可能会出现总金额比实际要多出1000的情况，因为它们在统计到用户C的储蓄金额时，会将用户A转帐后C的金额当作有效值参与到查询中，这种结果显然是不正确的。
  而ORACLE在处理到用户C的记录时会去找查询提交时间所对应的版本的记录，也就是A转帐到C之前的记录，显然这才是经理要得到的结果。
  由此看来，ORACLE的多版本，使得在不需要锁定的情况下，查询到的数据是同一时间的数据。
  这是不是意味着针对ORACLE数据库开发的查询就完全不需要锁来阻塞其他用户了呢？不是的
  以餐馆的订桌系统为例，假设用户通过查询来查看各个时间桌子是否被订了，然后再从没有被订的桌子中预定订某个时间某个桌子的使用权。
  如果这个系统是多用户的，那么就可能出现这种情况：甲乙两个用户同时查看当天下午五点的订桌情况，然后同时订下了1号桌。在没有对其它用户进行排它阻塞的情况下，两个用户同时看到1号桌没有被订，于是都下了订单，于是一张桌子同时被两人订了，这显然出了问题。
  正确解决这个问题，显然还是要使用用户阻塞的，也就是在查询时使用for update，这样在甲用户查询时，乙用户的查询就会被挂起，直到甲用户释放锁定之后才会执行，就不会出现上面这种情况了。
  ORACLE的多版本解决了数据的一致性问题，可以在不加锁的情况下获得同一时间的数据，然而这不意味着不需要在读取表的时候加锁了，类似上面的这种问题，往往很容易被忽略，而且这种bug很不容易找出来，何时用锁，何时不用，应当仔细。