时间：2021-07-01 10:21:17 帮助过：18人阅读
UNDO 表空间管理 1、对于DML语句来说，只要修改了数据块，Oracle数据库就会将修改前的数据块保留下来，保存在undo segment里面，
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
6、在buffer cache里面找到54号数据块，如果没有，则从10号数据文件调入
7、将改变后的值，也就是A放入54号数据块
8、由于数据块发生了变化，于是产生重做记录，假设重做记录号是121
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 专题页面 ?tid=12
