oracle多版本机制副作用

dyfiyxbkfd

　　     我们已经知道oracle多版本机制能够提供一致性的答案，而且还有高度的并发性。但是真的就没有其他不好的一面吗？
　　

　　      案例1：
　　      假设有一个资源调度程序（可以用来调度会议室，投影仪等资源），业务规则是：在给定的时间段不能将一种资源分配给多人。这里涉及到资源表（Resources）与资源调度表（Secludes）。
　　       我们一般的实现方式是，先查询某一时间段的某一资源是否已经被分配，如果没有被分配，我们就可以使用。
　　
　　       查看是否被分配SQL语句：
　　      select count(*)  from schedules where resource_name = :room_name 
　　      and (start_time <= :new_end_time)  and (end_time >= :new_start_time)。  ---SQL1
　　
　　      然后插入分配记录（如果得到结果为0）
　　      insert into schedules ( resource_name, start_time, end_time )
　　      values  ( p_resource_name, p_start_time, p_end_time );   ---SQL2
　　 
　　      但是如果我们让2个人同时预定13:00到14:00期间的投影仪资源，可能都会预定成功。假设一个人是事务A，另外一个人是事务B，在事务A执行SQL1语句的时候，事务B也开始执行SQL1语句（因为oracle里面查询是不会被阻塞的）。那么事务A与事务B查询的结果都是0，于是都可以申请到投影仪资源了。
　　
　　
　　      解决方案：
　　      应该在查询之前先锁定要申请的资源，使得事务A与事务B在执行SQL1与SQL2语句的时候串行。
　　
　　      在执行SQL1语句之前先执行如下SQL语句：
　　      select * from resources where resource_name = :room_name FOR UPDATE;  ---SQL3
　　
　　      这样当事务A执行完SQL3之后，事务B执行SQL3的时候就会被阻塞。除非事务B申请资源跟事务A不同。
　　
　　
　　     案例2：热表上超出期望的I/O
　　    在生产环境中在一个大负载条件下，一个查询使用的 I/O 比你在测试或开发系统时观察到的 I/O 要多得多。造成这种现象的原因是：在你测试系统中，由于它是独立的，所以不必撤销事务修改。不过，在生产系统中，读一个给定的块时，可能必须撤销（回滚）多个事务所做的修改，而且每个回滚都可能涉及I/O来获取undo信息并应用于系统。
　　     因为oracle提供多版本机制的原理是，读取数据的时候判断这个数据是不是已经被修改了，如果被修改了就从undo段去获取修改前的数据。如果发现这个修改前的数据还不是想要的数据，继续找更老的数据，直到找到开始执行SQL语句那一刻这个数据的值。
　　     所以在oracle里面如果一个表经常被修改，查询，会发生这样的情况。因为查询的时候，如果被修改的数据越多，需要读取undo段的信息就越长，I/O操作自然也会越多。对于这种热表的查询，最好能够把查询的时间压缩到最短，以便在查询期间，这个数据被其他事务修改的概率最低，从而需要从undo段读取的数据最少，最大限度减少I/O操作的概率。