oracle 多版本机制,关于oracle多版本机制副作用的问题-Oracle

我们已经知道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)  www.2cto.com

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操作的概率。

作者 liwenshui322