oracle事务之oracle读一致性

长平狐 发布于 2012/09/19 13:56
阅读 785
收藏 1

1回滚与撤销

      Refer:《深入解析oracleby eygle

(1)   为了多用户的读一致性和能回退事务,oracle提供了为修改的数据保存修改之前的旧值。

(2)   Redo:保证在故障时事务可以恢复

Undo:保证事务可以被回滚或撤销

(3)   9i之前,oracle提供回滚段(rollback)来撤销数据;之后,oracle使用undo表空间来管理。

(4)   下面这个例子是介绍9i前,是如何保证可以回滚的。

Update emp set sal=4000 where empno=7788

简单看一下这个语句的执行过程:

A:检查empno=7788记录在database buffer cache中是否存在;否,则读取到database buffer cache中。

B:在回滚表空间的相应回滚段事务表上分配事物槽,这个操作需要记录redo信息。

C:在回滚段读入或者在database buffer cache中创建sal=3000的旧值,这需要产生redo信息并记入redo log buffer

B,C这两步保证了事务的可回滚性,此后事务的修改才能进行】

D:修改sal=4000,这是update的数据变更,需要记录redo log buffer

F:当用户提交时,会在redo log buffer记录提交信息,并在回滚段标记该事务为非激活(inactive)。

(5)   如果用户回滚(rollback)事务,则oracle需要从回滚段中把旧值读取出来,修改database buffer cache,完成rollback,这个过程本身会产生redoso回滚是expensive

(6)   回滚段在undo表空间中分配,其作用:回退事务,事务恢复,提供读一致性。

对于DML

Insert:回滚段只需记录插入的记录的rowid

Update:回滚段只需记录被更新字段的旧值;

Deleteoracle必须记录整行的数据

所以,对产生undo的情况看,delete产生的undo最多,推荐对大规模数据删除操作时,分批删除,分次提交,以减少对回滚段的占用和冲击。

(7)   oracle区别于其他数据库的一个重要的特征:

通过多版本架构,oracle实现了读取和写入的分离,使得写入不阻塞读取,读取不阻塞写入。

多版本架构是通过一致性读来实现的。

      

 假定scott的薪水为3000

At1时刻我们在session 1 查询可以得到3000

Bt2时刻session 2进行update,但未提交(此时数据在database buffer cache中已经修改,该bufferdirty

Ct3时刻session 1再次查询,注意此时,oracle不会允许其他用户看到未提交的数据,oracle需要通过回滚段记录的旧值进行一致性读,将3000恢复出来给用户,这是一致性读的作用;

Dt4时刻,session 2提交该更改,此时数据修改已被永久化;

Ft5时刻,其他用户再次查询;将会看到变化后的数据,也就是4000.

      Notice

             A:每个数据块头部都会记录一个提交的SCN,当数据更改提交后,提交后,提交SCN同时被修改,这个SCN在查询时可以用来进行一致性读的判断。

             B:上图中,假定查询开始的时间为t1,则查询获取的数据块中,如果数据块的提交SCN小于t1,则oracle接收该数据【session 2便是这种情况】;如果提交SCN大于t1或者数据被锁定修改尚未记录提交SCN,则oracle需要通过回滚段构造前镜像来返回结果【session 1便是这种情景】,这就是一致性读的本质含义。

      89i之后,oracle引入了undo表空间,若选择自动的undo表空间管理,则oracle会动态创建和释放回滚段,自动为事务指定回滚段。

               命令:Show parameter undo

               里面有个参数undo_retentionORA_01555错误有关。

               这个参数可调:alter system set undo_retention=**;

               Undo_retention:当事务提交后undo信息保留的时间(秒);

               10g对于undo增加了guarantee控制:

                    Alter tablespace undotbs1 retention guarantee | noguarantee

                    区别:

                           若把undo表空间自动扩展属性取消:

                    Alter database datafile /u01/app/oracle/product/10.2.0/oradata/undotbs’

Autoextend off;

                    进行循环删除数据

                    guarantee设置下,会出现ORA-30036错误;

                    noguarantee设置下,则可以顺利完成,因为oracle启动自动调整以满足最长运行查询的需要。

      (9) ORA-01555成因与解决

             A:成因:

I)             由于回滚段是循环使用的,当事务提交后,该事务占用的回滚段事务表会被标识为inactive,回滚段表空间可以被覆盖重用。但是,当一个查询需要使用被覆盖的回滚段构造前镜像实现一致性读,那么就会出现著名的ORA-01555错误。

II)          未完待续。。。。。。。。。。

2    大师,你好!
  我在《深入浅出oracle》一书的167页的一句话不清楚,原话是:如果读取的block不满足读一致性需求,则server进程需要通过当前block版本和回滚段构造前镜像返回给用户。‘读一致性’是怎么判断出来的,被修改的数据要作排他锁,别人怎么读取那,盼回复,谢谢!

    根据SCN来判断阿。

3读一致性(Read Consistency,这是数据库的一个关键特性,可以确保用户在查询期间看到一致的数据。也就是说,当一个会话正在修改数据时,其他的会话将看不到该会话未提交的修改。

 

4事务的内部流程:

      1)首先,当一个事务开始时,需要在回滚段事务表上分配一个事务槽;

      2)在数据块头部获取一个ITL事务槽,该事务槽指向回滚段头的事务槽

      3)在修改数据前,需要记录前镜像信息,这个信息以undo recode的形式存储在回滚段中,回滚段头事务槽指向该记录;

      4)锁定修改行,修改行锁定位指向ITL事务槽。

      5)数据修改可以进行

5 Oracle数据库一致性读的原理

Oracle数据库中,undo主要有三大作用:提供一致性读(Consistent Read)、回滚事务(Rollback Transaction)以及实例恢复(Instance Recovery

一致性读是相对于脏读(Dirty Read)而言的。假设某个表T中有10000条记录,获取所有记录需要15分钟时间。当前时间为9点整,某用户A发出一条查询语句:select * from T,该语句在915分时执行完毕。当用户A执行该SQL语句到910分的时候,另外一个用户B发出了一条delete命令,将T表中的最后一条记录删除并提交了。那么到915分时,A用户将返回多少条记录?

如果返回9999条记录,则说明发生了脏读;如果仍然返回10000条记录,则说明发生了一致性读。很明显,在 9点钟那个时间点发出查询语句时,表T中确实有10000条记录,只不过由于I/O的相对较慢,所以才会花15分钟完成所有记录的检索。对于Oracle数据库来说,没有办法实现脏读,必须提供一致性读,并且该一致性读是在没有阻塞用户的DML的前提下实现的。

那么undo数据是如何实现一致性读的呢?还是针对上面的例子。用户A9点发出查询语句时,服务器进程会将9点那个时间点上的SCN号记录下来,假设该SCN号为SCN9.00。那么9点整的时刻的SCN9.00一定大于等于记录在所有数据块头部的ITL槽中的 SCN号(如果有多个ITL槽,则为其中最大的那个SCN号)。

:ITLInterested Transaction List)是Oracle数据块内部的一个组成部分,用来记录该块所有发生的事务,一个itl可以看作是一个记录,在一个时间,可以记录一个事务(包括提交或者未提交事务)。当然,如果这个事务已经提交,那么这个itl的位置就可以被反复使用了,因为itl类似记录,所以,有的时候也叫itl槽位。

服务器进程在扫描表T的数据块时,会把扫描到的数据块头部的ITL槽中的SCN号与SCN9:00之间进行比较,哪个更大。如果数据块头部的SCN号比SCN9.00要小,则说明该数据块在9点以后没有被更新,可以直接读取其中的数据;否则,如果数据块ITL槽的SCN号比SCN9.00要大,则说明该数据块在9点以后被更新了,该块里的数据已经不是9点那个时间点的数据了,于是要借助undo块。

9
10分,B用户更新了表T的最后一条记录并提交(注意,在这里,提交或者不提交并不是关键,只要用户B更新了表T,用户A就会去读undo数据块)。假设被更新记录属于N号数据块。那么这个时候N号数据块头部的ITL槽的SCN号就被改为SCN9.10。当服务器进程扫描到被更新的数据块(也就是N号块)时,发现其ITL槽中的SCN9.10大于发出查询时的SCN9.00,说明该数据块在9点以后被更新了。于是服务器进程到N号块的头部,找到SCN9.10所在的ITL槽。由于ITL槽中记录了对应的undo块的地址,于是根据该地址找到undo块,将 undo块中的被修改前的数据取出,再结合N号块里的数据行,从而构建出910分被更新之前的那个时间点的数据块内容,这样的数据块叫做CR块(Consistent Read)。对于delete来说,其undo信息就是insert,也就是说该构建出来的CR块中就插入了被删除的那条记录。随后,服务器进程扫描该 CR块,从而返回正确的10000条记录。

让我们继续把问题复杂化。假设在910B用户删除了最后一条记录并提交以后,紧跟着911分,C用户在同一个数据块里(也就是N号块)插入了2条记录。这个时候Oracle又是如何实现一致性读的呢(假设表Tinitrans1,也就是只有一个ITL槽)?因为我们已经知道,事务需要使用ITL槽,只要该事务提交或回滚,该ITL槽就能够被重用。换句话说,该ITL槽里记录的已经是SCN9.11,而不是SCN9.10了。这时,ITL槽被覆盖了,Oracle的服务器进程又怎能找回最初的数据呢?

其中的秘密就在于,Oracle在记录undo数据的时候,不仅记录了改变前的数据,还记录了改变前的数据所在的数据块头部的ITL信息。因此,910B用户删除记录时(位于N号块里,并假设该N号块的ITL信息为[Undo_block0 / SCN8.50]),则Oracle会将改变前的数据(也就是insert)放到undo块(假设该undo块地址为Undo_block1)里,同时在该undo块里记录删除前ITL槽的信息(也就是[Undo_block0 / SCN8.50])。删除记录以后,该N号块的ITL信息变为 [Undo_block1 / SCN9.10];到了911分,C用户又在N号块里插入了两条记录,则Oracle将插入前的数据(也就是delete两条记录)放到undo块(假设该undo块的地址为Undo_block2)里,并将911分时的ITL槽的信息(也就是[Undo_block1 / SCN9.10])也记录到该undo块里。插入两条记录以后,该N号块的ITL槽的信息改为 [Undo_block2 / SCN9.11]

那么当执行查询的服务器进程扫描到N号块时,发现SCN9.11大于SCN9.00,于是到ITL槽中指定的 Undo_block2处找到该undo块。发现该undo块里记录的ITL信息为[Undo_block1 / SCN9.10],其中的SCN9.10仍然大于SCN9.00,于是服务器进程继续根据ITL中记录的Undo_block1,找到该undo块。发现该undo块里记录的ITL信息为[Undo_block0 / SCN8.50],这时ITL里的SCN8.50小于发出查询时的SCN9.00,说明这时undo块包含合适的undo信息,于是服务器进程不再找下去,而是将N号块、Undo_block2以及Undo_block1的数据结合起来,构建CR块。将当前N号的数据复制到CR块里,然后在CR块里先回退911分的事务,也就是在CR块里删除两条记录,然后再回退910分的事务,也就是在CR块里插入被删除的记录,从而构建出9点钟时的数据。 Oracle就是这样,以层层嵌套的方式,查找整个undo块的链表,直到发现ITL槽里的SCN号小于等于发出查询时的那个SCN号为止。正常来说,当前undo块里记录的SCN号要比上一个undo块里记录的SCN号要小。

但是在查找的过程中,可能会发现当前undo块里记录的ITL槽的SCN号比上一个undo块里记录的SCN号还要大。这种情况说明由于事务被提交或回滚,导致当前找到的undo块里的数据已经被其他事务覆盖了,于是我们无法再找出小于等于发出查询时的那个时间点的SCN号,这时Oracle就会抛出一个非常经典的错误——ORA-1555,也就是snapshot too old的错误。



回滚事务则是在执行DML以后,发出rollback命令撤销DML所作的变化。Oracle利用记录在ITL槽里记录的undo块的地址找到该undo块,然后从中取出变化前的值,并放入数据块中,从而对事务所作的变化进行回滚。

实例恢复则是在SMON进程完成前滚并打开数据库以后发生。SMON进程会去查看undo segment头部(所谓头部就是undo segment里的第一个数据块)记录的事务表(每个事务在使用undo块时,首先要在该undo块所在的undo segment的头部记录一个条目,该条目里记录了该事务相关的信息,其中包括是否提交等),将其中既没有提交也没有回滚,而是在实例崩溃时被异常终止的事务全部回滚。

 

6缺省时,oracle表级锁为:S

                    行级锁为:X

一致性读
当会话发出一条SQL查询,将当前时间的SCN号记录下来,当进程扫描到表T的数据块,再与该块头部的ITL槽(事务槽)的SCN号比较,如果发现该块SCN号较小,则该块没有被更新过所以可用;如果该块SCN号较大,则该块被更新过,要借助UNDO块了,该块的ITL槽会记录了对应的UNDO块的地址,就取出对应的UNDO块,如果发现该UNDO块的ITL槽的SCN号也较大,证明也不可用,则在该块的ITL槽寻找再上一个块的UNDO块地址,层层递归,最终找到SCN号比发出查询的SCN号小的UNDO块。
因为UNDO块记录的是逻辑改变的值,例如INSERT操作记录在UNDO块就是DELETE,过程中,全部UNDO块一个一个地找出来,这有点增量改变的意思,再全部组成一起构成CR块以交给用户使用。
ORA-1555 snapshot too old
错误,须用UNDO块的时候,发现UNDO块被其他事务覆盖了,找不回了而出现的。

 

8为避免ORA-1555快照太旧的错误,出现了undo_retention参数,表示当事务提交或回滚后,该事务所使用的undo块里的数据需要保留多长时间,秒为单位。当保留的时间超过undo_retention所指定的时间以后,该undo块才能被其他事务覆盖。
默认情况下,ORACLE10g会每隔30秒就收集统计信息来自动调整undo retention,如果我们设定undo_retention0,或不设定,则启动此种模式,900秒为最低值;如果我们手动设定了undo_retention,则用我们指定的时间为undo保留的时间;
alter tablespace undoabc retention guarantee;
就保证了undo块一定能保留那么多时间。
alter tablespace undoabc retention noguarantee;
取消。

 

9不可重复读的重点在于修改:同样的条件,你读取过的数据,再次读取出来发现值不一样了

 幻读的重点在于新增或者删除:同样的条件, 1 次和第 2 次读出来的记录数不一样

 



 

 

 

 

 


原文链接:http://blog.csdn.net/linwaterbin/article/details/7651208
加载中
返回顶部
顶部