ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 事务隔离级别

事务隔离级别

原创 Linux操作系统 作者:zhouly1861 时间:2011-04-23 08:47:15 0 删除 编辑

ANSI/ISO SQL标准定义了4种事务隔离级别,对于相同的事务,采用不同的隔离级别分别有不同的结果。也就是说,即使输入相同,而且采用同样的方式来完成同样的工作,也可能得到完全不同的答案,这取决于事务的隔离级别。这些隔离级别是根据3个“现象”定义的,以下就是给定隔离级别可能允许或不允许的3种现象:
 脏读(dirty read):这个词不仅不好听,实际上也确实是贬义的。你能读取未提交的数据,也就是脏数据。只要打开别人正在读写的一个OS文件(不论文件中有什么数据),就可以达到脏读的效果。如果允许脏读,将影响数据完整性,另外外键约束会遭到破坏,而且会忽略惟一性约束。
不可重复读(nonrepeatable read):这意味着,如果你在T1时间读取某一行,在T2时间重新读取这一行时,这一行可能已经有所修改。也许它已经消失,有可能被更新了,等等。
 幻像读(phantom read):这说明,如果你在T1时间执行一个查询,而在T2时间再执行这个查询,此时可能已经向数据库中增加了另外的行,这会影响你的结果。与不可重复读的区别在于:在幻像读中,已经读取的数据不会改变,只是与以前相比,会有更多的数据满足你的查询条件。

更新丢失(Lost Update):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题--最后的更新覆盖了由其他事务所做的更新。

注意 ANSI/ISO SQL标准不只是定义了单个的语句级特征,还定义了事务级特征。在后面几页的介绍中,我们将分析事务级隔离,而不只是语句级隔离。
SQL隔离级别是根据以下原则定义的,即是否允许上述各个现象。我发现有一点很有意思,SQL标准并没有强制采用某种特定的锁定机制或硬性规定的特定行为,而只是通过这些现象来描述隔离级别,这就允许多种不同的锁定/并发机制存在(见表7-1)
表7-1 ANSI隔离级别
隔离级别 脏读 不可重复 幻像读
READ UNCOMMITTED(读未提交) 允许 允许 允许
READ COMMITTED(读已提交)  \  允许 允许
REPEATABLE READ(可重复读)  \  \ 允许
SERIALIZABLE(可串行化)  \  \  \
Oracle明确地支持READ COMMITTED(读已提交)和SERIALIZABLE(可串行化)隔离级别,因为标准中定义了这两种隔离级别。不过,这还不是全部。SQL标准试图建立多种隔离级别,从而允许在各个级别上完成的查询有不同程度的一致性。REPEATABLE READ(可重复读)也是SQL标准定义的一个隔离级别,可以保证由查询得到读一致的(read-consistent)结果。在SQL标准的定义中,READ COMMITTED不能提供一致的结果,而READ UNCOMMITTED(读未提交)级别用来得到非阻塞读(non-blocking read)。
不过,在Oracle中,READ COMMITTED则有得到读一致查询所需的所有属性。在其他数据库中,READ COMMITTED查询可能(而且将会)返回数据库中根本不存在的答案(即实际上任何时间点上都没有这样的结果)。另外,Oracle还秉承了READ UNCOMMITTED的“精神”。(有些数据库)提供脏读的目的是为了支持非阻塞读,也就是说,查询不会被同一个数据的更新所阻塞,也不会因为查询而阻塞同一数据的更新。不过,Oracle不需要脏读来达到这个目的,而且也不支持脏读。但在其他数据库中必须实现脏读来提供非阻塞读。
除了4个已定义的SQL隔离级别外,Oracle还提供了另外一个级别,称为READ ONLY(只读)。READ ONLY事务相对于无法在SQL中完成任何修改的REPEATABLE READ或SERIALIZABLE事务。如果事务使用READ ONLY隔离级别,只能看到事务开始那一刻提交的修改,但是插入、更新和删除不允许采用这种模式(其他会话可以更新数据,但是READ ONLY事务不行)。如果使用这种模式,可以得到REPEATABLE READ和SERIALIZABLE级别的隔离性。

READ UNCOMMITTED隔离级别允许脏读。Oracle没有利用脏读,甚至不允许脏读。READ UNCOMMITTED隔离级别的根本目标是提供一个基于标准的定义以支持非阻塞读。我们已经看到了,Oracle会默认地提供非阻塞读。在数据库中很难阻塞一个SELECT查询(如前所述,只是在分布式事务中对此有一个特殊的例外情况)。每个查询都以一种读一致的方式执行,而不论是SELECT、INSERT、UPDATE、MERGE,还是DELETE。这里把UPDATE语句称为查询可能很可笑,不过,它确实是一个查询。UPDATE语句有两个部分:一个是WHERE子句定义的读部分,另一个是SET子句定义的写部分。UPDATE语句会对数据库进行读写,就像所有DML语句一样。对此只有一个例外:使用VALUES子句的单行INSET是一个特例,因为这种语句没有读部分,而只有写部分。

SERIALIZABLE一般认为这是最受限的隔离级别,但是它也提供了最高程度的隔离性。SERIALIZABLE事务在一个环境中操作时,就好像没有别的用户在修改数据库中的数据一样。我们读取的所有行在重新读取时都肯定完全一样,所执行的查询在整个事务期间也总能返回相同的结果。例如,如果执行以下查询:
Select * from T;
Begin dbms_lock.sleep( 60*60*24 ); end;
Select * from T;
从T返回的答案总是相同的,就算是我们睡眠了24小时也一样(或者会得到一个ORA-1555:snapshot too old错误,这将在第8章讨论)。这个隔离级别可以确保这两个查询总会返回相同的结果。其他事务的副作用(修改)对查询是不可见的,而不论这个查询运行了多长时间。
Oracle中是这样实现SERIALIZABLE事务的:原本通常在语句级得到的读一致性现在可以扩展到事务级。
注意 前面提到过,Oracle中还有一种称为READ ONLY的隔离级别。它有着SERIALIZABLE隔离级别的所有性质,另外还会限制修改。需要指出,SYS用户(或作为SYSDBA连接的用户)不能有READ ONLY或SERIALIZABLE事务。在这方面,SYS很特殊。
结果并非相对于语句开始的那个时间点一致,而是在事务开始的那一刻就固定了。换句话说,Oracle使用回滚段按事务开始时数据的原样来重建数据,而不是按语句开始时的样子重建。
这里有一点很深奥——在你问问题之前,数据库就已经知道了你要问的问题的答案。
这种隔离性是有代价的,可能会得到以下错误:
ERROR at line 1:
ORA-08177: can't serialize access for this transaction
只要你试图更新某一行,而这一行自事务开始后已经修改,你就会得到这个消息。
注意 Oracle试图完全在行级得到这种隔离性,但是即使你想修改的行尚未被别人修改后,也可能得到一个ORA-01877错误。发生ORA-01877错误的原因可能是:包含这一行的块上有其他行正在被修改。
Oracle采用了一种乐观的方法来实现串行化
,它认为你的事务想要更新的数据不会被其他事务所更新,而且把宝押在这上面。一般确实是这样的,所以说通常这个宝是押对了,特别是在事务执行得很快的OLTP型系统中。尽管在其他系统中这个隔离级别通常会降低并发性,但是在Oracle中,倘若你的事务在执行期间没有别人更新你的数据,则能提供同等程度的并发性,就好像没有SERIALIZABLE事务一样。另一方面,这也是有缺点的,如果宝押错了,你就会得到ORA_08177错误。不过,可以再想想看,冒这个险还是值得的。如果你确实要更新信息,就应该使用第1章所述的SELECT … FOR UPDATE,这会实现串行访问。所以,如果使用SERIALIZABLE隔离级别,只要保证以下几点就能很有成效:
一般没有其他人修改相同的数据
需要事务级读一致性
事务都很短(这有助于保证第一点)
301 / 860
Oracle发现这种方法的可扩缩性很好,足以运行其所有TPC-C(这是一个行业标准OLTP基准:有关详细内容请见www.tpc.org)。在许多其他的实现中,你会发现这种隔离性都是利用共享读锁达到的,相应地会带来死锁和阻塞。而在Oracle中,没有任何阻塞,但是如果其他会话修改了我们也想修改的数据,则会得到ORA-08177错误。不过,与其他系统中得到死锁和阻塞相比,我们得到的错误要少得多。

写一致性
如果两个会话按顺序执行以下语句会发生什么情况呢?
Update t set y = 10 where y = 5;
Update t Set x = x+1 Where y = 5;

显然,我们不能修改块的老版本,修改一行时,必须修改该块的当前版本。另外,Oracle无法简单地跳过这一行,因为这将是不一致读,而且是不可预测的。在这种情况下,我们发现Oracle会从头重新开始写修改。

在这种情况下,Oracle会选择重启动更新。如果开始时Y=5的行现在包含值Y=10,Oracle会悄悄地回滚更新,并重启动(假设使用的是READ COMMITTED隔离级别)。如果你使用了SERIALIZABLE隔离级别,此时这个事务就会收到一个ORA-08177: can’t serialize access错误。采用READ COMMITTED模式,事务回滚你的更新后,数据库会重启动更新(也就是说,修改更新相关的时间点),而且它并非重新更新数据,而是进入SELECT FOR UPDATE模式,并试图为你的会话锁住所有WHERE Y=5的行。一旦完成了这个锁定,它会对这些锁定的数据运行UPDATE,这样可以确保这一次就能完成而不必(再次)重启动。
但是再想想“会发生什么……“,如果重启动更新,并进入SELECT FOR UPDATE模式(与UPDATE一样,同样有读一致块获取(read-consistent block get)和读当前块获取(read current block get)),开始SELECT FOR UPDATE时Y=5的一行等到你得到它的当前版本时却发现Y=11,会发生什么呢?SELECT FOR UPDATE会重启动,而且这个循环会再来一遍。
一致读和当前读
Oracle处理修改语句时会完成两类块获取。它会执行:
􀂉 一致读(Consistent read):发现”要修改的行时,所完成的获取就是一致读。
􀂉 当前读(Current read):得到块来实际更新所要修改的行时,所完成的获取就是当前读。
使用TKPROF可以很容易地看到这一点。请考虑以下这个很小的单行例子,它从先前的表T读取和更新一行:
ops$tkyte@ORA10GR1> alter session set sql_trace=true;
Session altered.
ops$tkyte@ORA10GR1> select * from t;
X
----------
10001
ops$tkyte@ORA10G> update t t1 set x = x+1;
1 row updated.
ops$tkyte@ORA10G> update t t2 set x = x+1;
1 row updated.
运行TKPROF并查看结果时,可以看到如下的结果(需要注意,我去掉了报告中的ELAPSED、CPU和DISK列):
select * from t
call count query current rows
------- ------ ------ ---------- ----------
Parse 1 0 0 0
Execute 1 0 0 0
Fetch 2 3 0 1
------- ------ ------ ---------- ----------
total 4 3 0 1
update t t1 set x = x+1
call count query current rows
------- ------ ------ ---------- ----------
Parse 1 0 0 0
Execute 1 3 3 1
Fetch 0 0 0 0
------- ------ ------ ---------- ----------
total 2 3 3 1
309 / 860
update t t2 set x = x+1
call count query current rows
------- ------ ------ ---------- ----------
Parse 1 0 0 0
Execute 1 3 1 1
Fetch 0 0 0 0
------- ------ ------ ---------- ----------
total 2 3 1 1
因此,在一个正常的查询中,我们会遇到3个查询模式获取(一致模式获取,query(consistent)mode get)。在第一个UPDATE期间,会遇到同样的3个当前模式获取(current mode get)。完成这些当前模式获取是为了分别得到现在的表块(table block),也就是包含待修改行的块;得到一个undo段块(undo segment block)来开始事务;以及一个undo块(undo block)。第二个更新只有一个当前模式获取,因为我们不必再次完成撤销工作,只是要利用一个当前获取来得到包含待更新行的块。既然存在当前模式获取,这就什么发生了某种修改。在Oracle用新信息修改一个块之前,它必须得到这个块的当前副本。

行触发器看到这一行有两个版本。行触发器会触发两次:一次提供了行原来的版本以及我们想把原来这个版本修改成什么,另一次提供了最后实际更新的行。由于这是一个BEFORE FOR EACH ROW触发器,Oracle看到了记录的读一致版本,以及我们想对它做的修改。不过,Oracle以当前模式获取块,从而在BEFORE FOR EACH ROW触发器触发之后具体执行更新。它会等待触发器触发后再以当前模式得到块,因为触发器可能会修改:NEW值。因此Oracle在触发器执行之前无法修改这个块,而且触发器的执行可能要花很长时间。由于一次只有一个会话能以当前模式持有一个块;所以Oracle需要对处于当前模式下的时间加以限制。
触发器触发后,Oracle以当前模式获取这个块,并注意到用来查找这一行的X列已经修改过。由于使用了X来定位这条记录,而且X已经修改,所以数据库决定重启动查询。注意,尽管X从1更新到2,但这并不会使该行不满足条件(X>0);这条UPDATE语句还是会更新这一行。而且,由于X用于定位这一行,而X的一致读值(这里是1)不同于X的当前模式读值(2),所以在重启动查询时,触发器把值X=2(被另一个会话修改之后)看作是:OLD值,而把X=3看作是:NEW值。

根据这些信息,我们可以进一步理解为什么使用AFTER FOR EACH ROW触发器比使用BEFORE FOR EACH ROW更高效。AFTER触发器不存在这些问题。

想 想看这会有什么潜在的影响。如果你有一个触发器会做一些非事务性的事情,这可能就是一个相当严重的问题。例如,考虑这样一个触发器,它要发出一个更新(电 子邮件),电子邮件的正文是“这是数据以前的样子,它已经修改成现在这个样子“。如果从触发器直接发送这个电子邮件,(在Oracle9i中使用UTL_SMTY,或者在Oracle 10g及以上版本中使用UTL_MAIL),用户就会收到两个电子邮件,而且其中一个报告的更新从未实际发生过。
如果在触发器中做任何非事务性的工作,就会受到重启动的影响。考虑以下影响:
􀂉 考虑一个触发器,它维护着一些PL/SQL全局变量,如所处理的个数。重启动的语句回滚时,对PL/SQL变量的修改不会“回滚“。
􀂉 一般认为,以UTL_开头的几乎所有函数(UTL_FILE、UTL_HTTP、UTL_SMTP等)都会受到语句重启动的影响。语句重启动时,UTL_FILE不会“取消“对所写文件的写操作。
􀂉 作为自治事务一部分的触发器肯定会受到影响。语句重启动并回滚时,自治事务无法回滚。
所有这些后果都要小心处理,要想到对于每一个触发器可能会触发多次,或者甚至对根本未被语句更新的行也会触发。
之所以要当心可能的重启动,还有一个原因,这与性能有关

 原子性(atomicity):事务中的所有动作要么都发生,要么都不发生。
 一致性(consistency):事务将数据库从一种一致状态转变为下一种一致状态。
隔离性(isolation):一个事务的影响在该事务提交前对其他事务都不可见。
持久性(durability):事务一旦提交,其结果就是永久性的。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8797129/viewspace-693229/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-08-03

  • 博文量
    53
  • 访问量
    106654