请教大师们
用户执行了commit 后为什么还要通过设置undo_retention  将临时段里的数据保留15分钟呢？有什么作用？

首先要明白undo_retention 作用是什么，假如现在有一个查询要执行10分钟，从9：00开始到9：10分结束（假设9：00时SCN为10000），在9：05分时有一个事务执行了一个DML语句修改了某个数据块（假设被修改的数据块是A），这个事务所需的时间非常短（几秒钟）然后就commit，此时被修改的数据块A的头部SCN号已经发生了变化假设为10001，由于数据库的事务非常多，这个DML事务所使用的UNDO空间又被其他的事务占用了，当最开始的查询语句读取到A数据块时发现SCN号比查询时的SCN（10000）大，这时ORACLE就会去根据ITL(事务槽)中记录的地址到回滚段中的事务表中查找（这个过程就是构造CR块的过程），由于原事务已经提交被其他事务覆盖，所以查询失败这时ORACLE会报ORA-01555(快照过旧)的错误，这时如果把undo_retention的值设置为900（15分钟），哪么查询就不会报错，因为所有事务在UNDO中最少要保留15分钟，这样第二个DML事务在回滚段中的数据就不会被其他事务覆盖，CR块就可以被重新构造出来，这样查询就可以得到一致性的结果；

chenyu、还可以继续分析。
今天晚上刚刚讲完。就是经典ORA-01555错误。
理解过程中的一个点很重要：即使是事务槽的改变，他的回滚信息也会出现在回滚段中。

希望老师在深入的讲讲，剩下的我也不太清楚了。

嗯，今天听了有点知道了

昨天晚上刚刚讲了课，就是ora-01555错误。
答题的场景：
8：50开始执行select（表很大）
8：55，一个session删除了这个表的最后一行，然后提交
8：56，一个session又在相同的位置插入了一行，假设使用的还是上一个事务的事务槽，然后提交，也就是说现在被修改的数据块的的事务槽中的scn是scn 8:56。
当select查询到达这个位置的时候，进行构造cr块，构造以后，发现数据块的事务槽中的scn是scn 8:56，显然还是大于scn 8:50，顺着往上继续构造cr块，一直到构造出cr块中的事务槽中的scn小于scn 8:50为止。
为什么可以顺着往上继续构造呢？因为回滚段中记录着不仅仅是数据行的改变前信息、还有事务槽的改变前信息。具体的图，请看我的ppt（关于回滚部分）。

此值的设定也只是oracle会尽量保存这个时间段的数据，如果undo过小事务过大同样也会覆盖数据,如果设置GUARANTEE值也会同样会报错吧。

"假设使用的还是上一个事务的事务槽"
这个假设是否成立？老师所描述的这种情况，根据我原先的理解：
因为8:56分的事务发现8:55的事务仍在undo_retention的时间范围内，所以就不会覆盖原先的事务槽。这样以后的事务就有了选择。
如果8:55的事务已经不在undo_retention的范围内，则8:56的事务可能覆盖8:55的事务槽，这种情况下无法继续往上构造CR块。

如果没有使用上一个事务的事务槽，那就更加简单了。
我们做的假设是一种极端的情况，假设事务也被新的事务覆盖了。
如果没有覆盖，那么就沿着两个事务槽继续找就可以了，而不需要沿着一个事务槽连续找两个已经提交的事务。

因为8:56分的事务发现8:55的事务仍在undo_retention的时间范围内，所以就不会覆盖原先的事务槽。这样以后的事务就有了选择。
张：你下面的两个问题，说明你的思路有些混乱。这和uno retention没有任何关系。
Oracle是否覆盖一个数据块事务槽的前提是：只要有已经提交的事务，尽量不扩展新的事务槽，因为这样会占用过多的数据块空间。
oracle并不怕覆盖一个事务槽，即使覆盖了这个事务槽，也不会出现01555操作，因为被覆盖的事务槽作为“修改前”数据进入了undo表空间。