事务隔离级别
ANSI/ISO SQL 标准定义了4 种事务隔离级别,这些隔离级别是根据3个“现象”定义的
1)脏读(dirty read)
能读取未提交的数据,也就是脏数据。
2)不可重复读(nonrepeatable read)
如果在T1时间读取某一行,在T2时间重新读取这一行时,这一行可能已经被修改,被删除,或者被更新等等。
3)幻像读(phantom read)
如果在T1 时间执行一个查询,而在T2时间再执行这个查询,返回结果中可能增加了另外的行。
它与不可重复读的区别在于:在幻像读中,已经读取的数据不会改变,只是与以前相比,会有更多的数据满足你的查询条件。
各个事务级别的定义->http://blog.csdn.net/fw0124/article/details/6227376
隔离级别 |
---|
幻像读
READ UNCOMMITTED
允许
允许
允许
READ COMMITTED
允许
允许
REPEATABLE READ
允许
SERIALIZABLE
Oracle支持READ COMMITTED和SERIALIZABLE这2种隔离级别,默认为EAD COMMITTED。
可以通过alter session set isolation_level = ?语句修改当前会话的隔离级别。
此外,Oracle还提供了另外一个级别,称为READ ONLY(只读)。READ ONLY 事务相对于无法在SQL中完成任何修改的REPEATABLE READ或SERIALIZABLE事务。
如果事务使用READ ONLY 隔离级别,只能看到事务开始那一刻提交的修改,但是不允许插入、更新和删除(其他会话可以更新数据,但是READONLY 事务不行)。
多版本读一致性(multi-version readconsistency)
Oracle现了一种多版本(multi-versioning)体系结构,这种体系结构提供了一种受控但高度并发的数据访问。
多版本是指,Oracle能同时物化多个版本的数据,这也是Oracle提供数据读一致视图的机制(read-consistent view 即相对于某个时间点有一致的结果)。
多版本有一个很好的副作用,即数据的读取器(reader)绝对不会被数据的写入器(writer)所阻塞。换句话说,写不会阻塞读。这是Oracle 与其他数据库之间的一个根本区别。在Oracle中,如果一个查询只是读取信息,那么永远也不会被阻塞。它不会与其他会话发生死锁,而且不可能得到数据库中根本不存在的答案。
默认情况下,Oracle的读一致性多版本模型应用于语句级(statement level),对应于READ COMMITTED隔离级别,也就是说,至少提交到数据库的每一条SQL 语句都会看到数据库的一个读一致视图。
另外还可以应用于事务级(transaction level),对应于SERIALIZABLE隔离级别。
通过下面的例子来理解多版本,读一致性和非阻塞读的含义:
需要查询一个ACCOUNTS表,其中包含了银行的账户余额,
create table accounts(
account_number number primary key,
account_balance number
);
现在ACCOUNTS表格里的数据如下:
ACCOUNT_NUMBER ACCOUNT_BALANCE
-------------- ---------------
1 500
2 250
3 400
4 100
通过下面的语句查询帐户总额,
select sum(account_balance) from accounts;
现在假设当已经读取了第1行,准备读取第2行和第3行时,一台自动柜员机(ATM)针对这个表发生了一个事务,将$400.00从账户1转到了账户4,结果怎样?
在几乎所有的其他数据库中,如果想得到“一致”和“正确”的查询答案,就必须在计算总额时对整个表加上共享读锁,但这会大大影响并发性。
通过使用会滚段(Undo段),Oracle则不需要任何锁定,就可以得到正确答案。Oracle是这样做的:
--------------------------------------------------------------
时间 查询 转账事务
--------------------------------------------------------------
T1 读第1行;到目前为止sum = $500
T2 更新第1行;对第1行加一个排他锁(也称独占锁,
exclusive lock),阻止其他更新。第1行现在有$100
T3 读第2行;到目前为止sum = $750
T4 读第3行;到目前为止sum = $1150
T5 更新第4行;对第4 行加一个排他锁,阻止其他更新(但不
阻止读操作)。第4行现在有$500
T6 读第4行,发现第4行已修改。这会
将块回滚到T1时刻的状态。查询从
这个块读到值$100
T7 提交事务
T8 得到答案sum = $1250
SERIALIZABLE隔离级别和读一致性
使用SERIALIZABLE事务隔离级别在一个环境中操作时,就好像没有别的用户在修改数据库中的数据一样。我们读取的所有行在重新读取时都肯定完全一样,所执行的查询在整个事务期间也总能返回相同的结果。
例如,如果执行以下查询:
select * from ACCOUNTS;
exec dbms_lock.sleep( 60*60*24 );
select * from ACCOUNTS;
2次从ACCOUNTS返回的结果总是一样的,即使是在这个期间别的会话修改了ACCOUNTS的数据。这种情况下,Oracle会使用回滚段按事务开始时数据的原样来重建数据。
但是如果现在我们准备更新某一行,而在这之前(我们第一次执行select * from ACCOUNTS之后),别的事务也更新了这一行,那么就会得到一个错误
ORA-08177: can't serialize access for this transaction
(实际上并不需要是同一行上发生修改,只要包含这一行的块上有其他行已经被修改,就会发生这个错误)
保证以下几点情况下,适合使用SERIALIZABLE隔离级别:
· 一般没有其他人修改相同的数据
· 需要事务级读一致性
· 事务都很短
READ ONLY隔离级别和读一致性
READ ONLY事务与SERIALIZABLE事务惟一的区别是READ ONLY事务不允许修改,因此不会遭遇ORA-08177错误。
在READ ONLY事务中可能会看到ORA-1555:snapshot too old错误。
如果其他的会话正在修改你在READ ONLY事务中读取的数据,就有可能发生这种情况。因为READ ONLY事务需要读取记录在回滚段中的修改前的这些数据(undo信息),把它们恢复到块缓冲区。但是回滚段以一种循环方式使用,这与重做日志非常相似。READ ONLY事务运行的时间越长,重建数据所需的undo信息就越有可能已经被覆盖了,此时,就会得到ORA-1555错误。
对于这个问题,惟一的解决方案就是为系统适当地确定回滚段大小。
热表上超出期望的I/O
使用READ ONLY事务与SERIALIZABLE事务可能导致超出期望的I/O。如果其他的事务大量修改了我们的事务需要读取的记录,就会发生这种现象。原因就是Oracle会查找undo信息,撤销其他事务所做的修改。甚至是其他事务只是很多次反复修改了少量记录,也会造成这种现象,Oracle撤销了修改,把被修改的块从回滚段恢复到块缓冲区,之后发现这个会滚块还是太新,然后继续回滚,反复进行,直到找到事务开始时的那个版本,这就会导致大量的I/O来读取回滚段。(这也说明块缓冲区中可能包含一个块的多个版本)
不仅仅是READ ONLY事务与SERIALIZABLE事务才会有这种现象,如果一个查询语句运行的时间很长,也会有可能遇到同样问题。运行时间越长,可能需要更多工作才能从块缓冲区(通过回滚)获得数据,就可能会运行的更久,这是一个恶性循环。