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