Oracle 11g undo_retention 以及retention guarantee 小结

undo 里面记录的是被修改的数据块的前镜像，但是他并不是原数据块的copy，而是一个改变向量，真正的一致性读要借助CR块，Cr块也就是consistent read块它用来维护Oracle的读一致性的数据块。当查询某些数据的时候，发现数据块的版本比我们要查询的新，例如session1执行了dml操作并没有提交，session2此时查找跟session1相关的dml操作的数据信息，此时查询的数据却是原来的数据信息。
查询的过程会在undo段中查找该数据块的前映像后，然后把前映像和current块合并形成了一个CR block，通过查询cr block就可以满足数据的一致性了。

CR block存在于sga的buffer cache中，在db cache里申请一个数据块（当前块），然后和对应的回滚段的前映像生成cr block。

关于undo的参数：

SQL> show parameter undo

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

undo_management string AUTO

undo_retention integer 900

undo_tablespace string UNDOTBS1

从11g开始oracle默认都是undo tablespace 自动管理，并且如果你没有指定undo_tablespace 这个参数，也就是说没有undo表空间，那么oracle就会把修改块的前镜像放到system表空间里面，并且会在alert日志里面告警：数据库 running without an undo tablespace。

下面重点解释 undo_retention 

我们知道undo segments的extents 的状态共有四种，free ,active , inacitve, expired 
SQL> select SEGMENT_NAME,TABLESPACE_NAME,STATUS from  dba_undo_extents;

SEGMENT_NAME                  TABLESPACE_NAME                STATUS
------------------------------ ------------------------------ ---------
_SYSSMU10_3534552179$          UNDOTBS1                      EXPIRED
_SYSSMU10_3534552179$          UNDOTBS1                      EXPIRED
_SYSSMU10_3534552179$          UNDOTBS1                      UNEXPIRED
_SYSSMU10_3534552179$          UNDOTBS1                      EXPIRED
_SYSSMU10_3534552179$          UNDOTBS1                      EXPIRED
_SYSSMU10_3534552179$          UNDOTBS1                      EXPIRED
_SYSSMU9_3683992930$          UNDOTBS1                      EXPIRED
_SYSSMU9_3683992930$          UNDOTBS1                      EXPIRED
_SYSSMU9_3683992930$          UNDOTBS1                      EXPIRED

    1）free：没有分配给任何一个段
    2）active：区中有事务没有提交
    3）inactive：区中的事务提交了但是还没有达到  undo_retention 的时间
    4）expired：事务提交而且达到了undo_retention
    注：我们可以通过设定undo_retention来保住inactive的区，若没有free，则自动扩展；若扩展不了，则优先使用expired；若还不够，则就会使用inactive，但如果此时retention是guarantee保证的（也就是ALTER TABLESPACE undotbs1 RETENTION GUARANTEE），则无法使用inactive，会报ORA-30036。
小结 ：如果你倾向于保证数据一致性，也就是专注于查询，那么你有必要通过ALTER TABLESPACE undotbs1 RETENTION GUARANTEE，来保证一致性，也就是不管你空间够不够用，你都不可以使用inactive状态的区，这样就有可能导致由于没有可用的undo空间而导致数据库hang住，但是这样你可以保证查询语句执行时间在  undo_retention值 之内的所有查询 的一致性。如果你的业务倾向于事务，你可以不去设置  RETENTION GUARANTEE，这样当没有可用的undo空间时，可以去覆盖inactive状态的区，这样就有可能报错ora-01555，不能一致读了，因为你的undo_retention 值是通过咨询你们当前业务的查询语句执行时间最长的那个时间来确定的，也就是说undo_retention > sql执行最长时间，因此你使用不使用GUARANTEE取决于你业务的需求。