oracle事务隔离级别_笔记3:REPEATABLE READ

REPEATABLE READ

REPEATABLE READ的目标是提供这样一个隔离级别，它不仅能给出一致的正确答案，还能避免丢失更新。

1、得到一致的答案

如果隔离级别是REPEATABLE READ，从给定查询得到的结果相对于某个时间点来说应该是一致的。大多数数据库(不包括Oracle)都通过使用低级的共享读锁来实现可重复读。共享读锁会防止其他会话修改我们已经读取的数据。当然，这会降低并发性。Oracle则采用了更具并发性的多版本模型来提供读一致的答案。

在Oracle中，通过使用多版本控制，得到的答案相对于查询开始执行那个时间点是一致的。在其他数据库中，通过使用共享读锁，可以得到相对于查询完成那个时间点一致的答案，也就是说，查询结果相对于我们得到答案的那一刻是一致的。

在一个采用共享读锁来提供可重复读的系统中，可以观察到，查询处理表现中的行时，这些行都会锁定。

我们得到了正常的答案，但是这是有代价的：需要物理地阻塞一个事务，并且顺序执行两个事务。

这是使用共享读锁来得到一致答案的副作用之一：数据的读取器会阻塞数据的写入器。不仅如此，在这些系统中，数据的写入器还会阻塞数据读取器。共享读锁会妨碍并发性，而且还会导致有欺骗性的错误。

共享读锁的另一个副作用：数据的读取器和写入器可能而且经常相互死锁。

Oracle中可以得到语句级的读一致性，而不会带来读阻塞写的现象，也不会导致死锁。Oracle从不使用共享读锁。Oracle选择了多版本控制机制，尽管更难实现，但绝对更具并发性。

2、丢失更新：另一个可移植性问题

在一个采用共享读锁(而不是多版控制)的数据库中，如果启用了REPEATABLE READ，则不会发生丢失更新错误。这些数据库中之所以不会发生丢失更新，原因是：只要选择数据就会在上面加一个锁，数据一旦由一个事务读取，就不能被任何其他事务修改。如此说来，如果你的应用认为REPEATABLE READ就意味着“丢失更新不可能发生”，等你把应用移植到一个没有使用共享读锁作为底层并发控制机制的数据库时，就会痛苦地发现与你预想的并不一样。

尽管听上去使用共享读锁好像不错，但如果读取数据时在所有数据上都加共享读锁，这肯定会严重地限制并发读和修改。

本文来源 我爱IT技术网 http://www.52ij.com/jishu/5220.html 转载请保留链接。