Oracle基础教程之管理还原数据


UNDO 表空间管理

1、对于DML语句来说,只要修改了数据块,Oracle数据库就会将修改前的数据块保留下来,保存在undo segment里面,而undo segment则保存在undo表空间中

2、undo的管理

自动undo管理(Oracle9i开始)AUM

手工undo管理MUM

9i以后,就建议使用AUM,因此就不再讨论MUM

一条DML语句的执行流程update t set coll=‘A’ where coll=‘B’

1、在shared pool里面进行解析,从而生成执行计划

2、根据执行计划,得出coll=‘B’的记录存放在10号数据文件的54号数据块里面

3、服务器进程首先在buffer cache寻找一个可用的undo数据块(如果一个事物已经提交,那么这个事务曾经使用过的undo数据块就可以被使用),如果没有发现,则到undo表空间里找到一个可用的undo数据块,并调入到buffer cache。假设获得的undo数据块号为24号,位于11号undo数据文件里

4、将改变前的值,也就是B放入24号undo数据块(buffer cache中)

5、由于undo数据块发生了变化(只要是数据块发生变化,那么就产生重做记录),于是产生重做记录,假设重做记录号是120

clip_image001

6、在buffer cache里面找到54号数据块,如果没有,则从10号数据文件调入

7、将改变后的值,也就是A放入54号数据块

8、由于数据块发生了变化,于是产生重做记录,假设重做记录号是121

clip_image002

9、控制权返回给用户,如果使用SQLPLUS,那么表现为光标返回

10、用户发出commit命令,触发LGWR,将120、121这两个重做记录写入联机重做日志文件中,将54号、24号两个数据块头部所记录的事务状态标记设置为已提交,控制权返回给用户,如果使用SQLPLUS,那么表现为光标返回

11、这个时侯,54号和24号数据块并不一定被DBWr写入数据文件,只有在脏数据块的数量达到一定程度的时候才会被写入

事务提交以后,该事务所使用的undo数据块就可以被覆盖,上面的例子中,第10步用户提交以后,24号undo数据块就可以被覆盖

Undo的作用

1、提供读一执性

2、回滚事务

3、实例恢复

读一致性

一个场景描述

读一致性是相对脏读而言的,表T中有10000条记录,获取所有的记录需要15分钟的时间,当前时间为9点整,用户发出一条select * from T命令,该语句在9:15完成。当用户执行该语句到9:10分的时候,另外一个用户发出了一条删除命令,将最后一条记录删除,并且进行了提交。

到9点15分的时候,用户返回了多少条记录。

如果是9999条,那么就是脏读、如果是10000条,那么就是读一致性。

Oracle不会出现脏读,提供读一致性,而且没有阻塞DML操作

Oracle如何实现读一致性呢?

1、用户在9点发出select语句的时候,服务器进程会记录9点那个时刻的SCN号(SCN号是以时间(timestamp)作为参数的一个函数返回值,调用函数(默认以timestamp为参数)随时可以返回这个时刻的SCN号,可以使用函数在SCN和timestamp之间进行转换),假设该SCN号是SCN9:00,那么SCN9:00一定大于等于记录在所有数据块头部的ITL槽中的SCN号(如果有多个ITL槽,SCN最大的那个)

2、服务器进程扫描T表的时候,会把扫描的数据块头部的ITL槽中的SCN号与SCN9:00进行比较,哪个更大。如果数据块头部的SCN小于SCN9:00,那么说明这个数据块在9:00以后没有更改过,可以直接读取,如果数据块头部的SCN号大于SCN9:00,则说明该数据块在9:00以后更改过,已经不是9:00那个时刻的数据了于是要借助undo块

3、9点10分,用户更改了T表的最后一条记录并提交(无论是否提交,只要是更改了T表,用户就会去读undo数据块),假设被更改的是N号数据块,那么N号数据块头部的ITL槽中记录的SCN被修改为SCN9:10,当服务器进程扫描到这个数据块的时候,发现ITL槽中的SCN9:10大于SCN9:00,说明该数据块在9:00以后被更新了,于是服务器进程到N号块的头部,找到SCN9:10所在ITL槽,由于ITL槽记录了对应的undo块的地址,于是服务器进程找到undo数据块,结合undo数据块给用户提供读一致性。

更多Oracle相关信息见Oracle 专题页面 http://www.bkjia.com/topicnews.aspx?tid=12

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 下一页

相关内容