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数据块给用户提供读一致性。
进一步复杂化问题
1、9点10分，更新了数据并且进行了提交，9点11分又对该数据块进行了更新并且提交（假设数据块只有一个ITL槽）
2、那么该ITL槽记录的就是SCN9：11
3、这种情况如何处理，秘密在于undo数据块中，除了记录改变前的数据以外，因为数据块的ITL槽也发生了变化，因此也进行了记录，而ITL槽中记录了undo块的地址。9：00的时候数据块的ITL槽中记录了数据块的SCN是8：50和对应的undo块，9：10分的时候数据库的ITL槽中记录了数据块的SCN是9：10和对应的undo（undo1），9：11分的时候数据库的ITL槽中记录了数据块的SCN是9：11和对应的undo（undo2），Undo2中记录了9：10的数据，以及9：10数据的undo地址undo1，undo1中记录了9点以前的数据以及9点以前的undo数据
当用户进行查询的时候，服务器进程扫描到N号数据块，发现SCN9：11，大于SCN9：00，从ITL槽中找到undo块的地址（undo2），undo2中记录了改变前的数据和改变前的数据库的ITL槽，发现undo2对应的SCN是9：10还是大于9：00，根据undo里面记录的ITL槽的改变前信息，继续向前找，找到undo1，发现SCN是8：50，小于9：00，使用这个undo的数据
如果在向前寻找的时候，没有找到SCN小于9：00的数据（因为时间比较长，而且事务已经提交，所以回滚段可能被覆盖），数据库就会出现一个经典的错误ORA-01555（snapshoot too old），但是不会出现脏读的情况。
最核心的就是：数据块的数据发生改变，ITL槽也发生改变。这两条信息都会存储到undo中。因此如果一个undo足够的大，那么一个数据块的所有的undo数据块是可以串联起来的。可以从最近一直找到非常远的过去。从数据块开始往前找，一直找到很久以前的SCN。这个数据块所有的变化都能够找到。
ITL槽中记录着这个数据块的undo数据块的地址。
一个数据块中存储很多条数据，update、insert、delete等DML操作，都会影响数据块的SCN号。数据块的SCN号反映了数据块的变化过程。
回滚事务：错误或者rollback命令都会产生回滚
根据ITL槽中记录的undo数据块的地址，找到undo数据块，恢复数据。
实例恢复
回滚段的头部记录了事务表，每一个事务是否提交等信息都存储在里面。
根据事务表的信息进行实例恢复。
配置AUM
Oracle9i开始，我们不再使用手工的管理方式，因此“MANUAL”不再使用，使用“AUTO”
使用AUM需要配置两个参数
指定这两个参数以后，剩余的工作让Oracle来处理，例如undo segment的创建、扩展、收缩、删除等。
如果指定了undo_management，但是在指定undo_tablespace的时候，指定了一个错误的回滚表空间，实例启动的时候，会报错。
如果没有指定回滚段表空间，系统查找第一个可用的回滚段表空间，如果没有找到，那么就使用system表空间中的回滚段，这不是我们希望看到的，因为对性能影响很大。
因此两个参数都要很好的规划
事务、undo segment
发生DML操作的时候，服务器进程会选择一个undo segment，具体算法如下：
1、首先尝试将每一个undo segment绑定一个事务，也就是每个undo segment上只有一个事务使用
2、如果不能发现完全空闲的undo segment，所有的undo segment都与事务绑定
3、系统尝试将脱机的undo segment联机
4、如果没有可用的undo segment进行联机，则会尝试创建一个新的undo segment
5、如果上面的步骤都没有成功（例如没有可用空间了，不能创建undo segment），算法会尝试寻找最早使用的undo segment，这种情况下，不同的多个事务会在同一个相同的undo segment里同时进行
6、每隔12个小时会收缩一次，删除那些idle状态的extent
7、DML操作需要undo时，发现空间不够，则会唤醒SMON进行一次收缩，将undo segment里面暂时没有使用的extent拿过来使用
Oracle 在提供一致性读的过程中，具体的步骤如下
1、确认读时刻的SCN
2、搜寻所有的数据块的SCN要求小于读时刻的SCN
3、如果搜寻的SCN小于读时刻的SCN，直接读取
4、如果搜寻的SCN大于读时刻的SCN，根据数据块里面的ITL槽里面记录的undo信息，找到改变前的数据、如果SCN还是大，顺着ITL槽信息串联起来的undo块继续向前找
5、如果没有找到小于读时刻的SCN的数据块，那么就报错ORA-01555
事务提交以后，undo回滚段就可以被覆盖，而且我们在寻找undo数据块的时候，这个被寻找的undo数据块很可能已经被提交，因此出现ORA-01555错误不可避免。Oracle是如何来解决这个问题的呢？
Oracle定义了一个参数undo_retention
这个参数以秒为单位，表示当事务提交或者回滚以后，该事务所使用的undo 块里的数据需要保留多长时间。
当保留的时间超过undo_retention所指定的时间以后，该undo块才能够被其他事务覆盖。
当我们使用AUM的时候，并且设置了undo_retention以后，undo块的状态就存在4种
Active：表示正在使用该数据块的事务还没有提交或者回滚
Inactive：该数据块上没有活动的事务，该状态的undo可以被其他事务覆盖
Expired：该数据块持续inactive的时间超过undo_retention所指定的时间
Freed：该数据块是空的，从来没有被使用过
在AUM模式中，事务可以在不同的undo segment之间动态交换undo空间，也就是在不同的undo segment里交换extents。
我们来看一下，一个事务需要更多的undo空间的时候，是如何进行处理的？
1、获取undo表空间里可用的、空的extents（segment的最小分配单元是extent）
2、获取其他undo segment里的expired状态的extents
3、如果undo表空间里的数据文件启用了自动扩展，则数据文件进行自动扩展
4、如果undo表空间里的数据文件没有启用自动扩展，则获取undo segment里的inactive状态的extents
5、如果还是没有获得可用空间，报空间不足的错误
1、undo表空间中一共存在5个undo segment
2、每个undo segment包括7个extents
3、当使用US5的事务需要额外的空间的时候，首先使用两个F状态的extent，如果还不够用，继续使用US4里面三个F状态的extents，如果还不够用，使用US3里面X状态的extents，如果还不够用，继续使用US1里面I状态的extent，如果还不够用，报空间不足的错误。
假设上面的数据文件没有配置自动扩展
1、AUM里面分配extent的方式是高效率的，而且尽量避免使用I状态的extent。
2、在Oracle10g里面，如果undo表空间足够，那么Oracle会将undo信息保留的时间与当前运行时间最长的查询所需要的时间相同（一个很好的优势，最大限度的避免了ORA-01555）
3、默认情况下，Oracle每隔30秒就收集统计信息来自动调整undo retention，收集的信息包括运行时间最长的查询与产生undo的速度
我们通过设置undo_retention为0，那么就使用上面的自动调整功能，而且以900秒为最低限
如果我们设置了undo_retention，那么就使用这个参数作为undo_retention的值，不再支持动态的调整undo_retention
4、如果undo_retention设置为0，则实例会获取运行时间最长的那个查询所需要的时间，例如N秒，然后将undo信息保留N秒，当undo表空间尺寸太小时，而不能保留这个最长时间，则尽可能的利用现有空间来让undo保留的时间尽可能的长，并不会立刻扩展undo数据文件，除非要覆盖的undo信息是在900秒以内发生的，才会去扩展数据文件。
管理undo表空间
1、一些常规性的操作，例如添加数据文件、重命名数据文件、将数据文件联机或者脱机，和普通的表空间操作没什么两样。
可以通过EM来进行操作
2、一个数据库可以有多个undo表空间，但是在一个时刻，只能有一个undo表空间起作用，通过参数undo_tablespace设置来指定一个undo表空间
上面做了一个undo 表空间的切换
1、旧的表空间上有事务正在执行，则该旧的表空间变成pending offline。
2、用户事务正常运行，切换操作结束，不会等待旧的undo表空间的事务结束
3、切换以后，所有新的事务所产成的undo数据不会存放在旧的undo表空间，而是会使用新的undo表空间
4、pending offline状态的undo表空间不能被删除
5、旧的undo表空间上的所有的事务都提交以后，旧的undo表空间从pending offline状态变成offline状态，表空间可以删除
6、drop tablespace undotbs1相当于drop tablespace undotbs1 including contents
7、如果undo表空间包含inactive状态的undo数据块，不影响被删除，但是可能产生ORA-01555错误，因此最好等待超过undo_retention以后，再删除表空间
创建第三个undo表空间
创建表test并插入一条数据
显示当前的活动事务，以及对undo的使用。
Undo表空间直接被删除，为什么呢？
因为我们认为在undo表空间上有活动事务。
因为在同一个会话中，如果有DDL语句，那么前面的事务会被提交。
检查回滚段里的信息
插入一条数据，继续检查回滚段里的信息
另起一个会话，切换了undo表空间。
会话还在，没有被提交。
表空间不能被删除。
回到原来的会话中，将事务提交。
已经没有会话，为什么还不能被删除。
这就涉及了另外一个话题
Undo_retention参数不能保证undo信息保留足够的时间，oracle只是尽量的保证undo数据块不被覆盖掉，当空间不够的时候，Oracle还是会将保留时间小于undo_retention的undo数据覆盖掉。
从Oracle 10g开始，我们可以在建立undo表空间的时候，设置retention guarantee属性，从而让不会出现上面的情况。
也就是说
当undo数据文件不能扩展，并且undo信息不够用时，直接报错，而不是覆盖那些inactive而又没有expired的undo块。
经过15分钟以后，也就是undo_retention以后，表空间可以被删除。
表空间的这个参数是可以修改的。
设置Undo表空间的大小
1、借助视图，看一下每隔十分钟产生的undo块的数量，oracle会保留最近7天的数据
如果数据库启动足够长的时间，那么会保留7天的数据，也就是1008行数据。
有公式可以计算如何设置undo的大小。但是我们最好还是借鉴Oracle提供的advisor。
根据系统的负载，不同的还原保留时间所需要的undo空间。