在undo自动管理时，设置了undo_retention以后，undo块就存在四种状态。Active：表示正在使用该undo的事务还没有提交或回滚。Inac
在undo自动管理时，设置了undo_retention以后，undo块就存在四种状态。
Active：表示正在使用该undo的事务还没有提交或回滚。
Inactive：表示该undo上没有活动的事务，该状态的undo可以被其他事务覆盖。
Expired：表示该undo持续inactive的时间超过undo_retention所指定的时间。
Freed：表示该undo块内容是空的，从来没有被使用过。
Undo Retention
After a transaction is committed, undo data is no longer needed for rollback or transaction recovery purposes. However, for consistent read purposes, long-running queries may require this old undo information for producing older images of data blocks. Furthermore, the success of several Oracle Flashback features can also depend upon the availability of older undo information. For these reasons, it is desirable to retain the old undo information for as long as possible.
When automatic undo management is enabled, there is always a current undo retention period, which is the minimum amount of time that Oracle Database attempts to retain old undo information before overwriting it. Old (committed) undo information that is older than the current undo retention period is said to be expired. Old undo information with an age that is less than the current undo retention period is said to be unexpired.
Oracle Database automatically tunes the undo retention period based on undo tablespace size and system activity. You can specify a minimum undo retention period (in seconds) by setting the UNDO_RETENTION initialization parameter. The database makes its best effort to honor the specified minimum undo retention period, provided that the undo tablespace has space available for new transactions. When available space for new transactions becomes short, the database begins to overwrite expired undo. If the undo tablespace has no space for new transactions after all expired undo is overwritten, the database may begin overwriting unexpired undo information. If any of this overwritten undo information is required for consistent read in a current long-running query, the query could fail with the snapshot too old error message.
The following points explain the exact impact of the UNDO_RETENTION parameter on undo retention:
The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace. The database may overwrite unexpired undo information when tablespace space becomes low.
For an undo tablespace with the AUTOEXTEND option enabled, the database attempts to honor the minimum retention period specified by UNDO_RETENTION. When space is low, instead of overwriting unexpired undo information, the tablespace auto-extends. If the MAXSIZE clause is specified for an auto-extending undo tablespace, when the maximum size is reached, the database may begin to overwrite unexpired undo information.
Automatic Tuning of Undo Retention
Oracle Database automatically tunes the undo retention period based on how the undo tablespace is configured.
If the undo tablespace is fixed size, the database tunes the retention period for the best possible undo retention for that tablespace size and the current system load. This tuned retention period can be significantly greater than the specified minimum retention period.
If the undo tablespace is configured with the AUTOEXTEND option, the database tunes the undo retention period to be somewhat longer than the longest-running query on the system at that time. Again, this tuned retention period can be greater than the specified minimum retention period.
Note:
Automatic tuning of undo retention is not supported for LOBs. This is because undo information for LOBs is stored in the segment itself and not in the undo tablespace. For LOBs, the database attempts to honor the minimum undo retention period specified by UNDO_RETENTION. However, if space becomes low, unexpired LOB undo information may be overwritten.
You can determine the current retention period by querying the TUNED_UNDORETENTION column of the V$UNDOSTAT view. This view contains one row for each 10-minute statistics collection interval over the last 4 days. (Beyond 4 days, the data is available in the DBA_HIST_UNDOSTAT view.) TUNED_UNDORETENTION is given in seconds.
select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time, tuned_undoretention
from v$undostat order by end_time;
BEGIN_TIME END_TIME TUNED_UNDORETENTION
--------------- --------------- -------------------
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
04-FEB-05 00:01 04-FEB-05 00:11 12100
...
07-FEB-05 23:21 07-FEB-05 23:31 86700
07-FEB-05 23:31 07-FEB-05 23:41 86700
07-FEB-05 23:41 07-FEB-05 23:51 86700
07-FEB-05 23:51 07-FEB-05 23:52 86700
576 rows selected.
RMAN备份与恢复之undo表空间丢失
关于Oracle 释放过度使用的undo表空间
Oracle undo的一些理解
Oracle undo 镜像数据探究
Oracle 回滚(ROLLBACK)和撤销(undo)
回滚段自动管理模式下UNDO block分配算法：
1、如果当前extent有空闲的数据块，则使用当前extent
2、如果当前extent的下一个extent已经处于过期（expired）状态，那么环绕（wrap）到一个extent，，然后使用该extent的第一个数据块。
3、如果下一个extent没有expired，则从undo tablespace中分配空间。如果有剩余空间则使用新分配extent的第一个数据块。此时undo tablespace的使用率开始增加。
4、如果没有剩余空闲的extent，则从offline状态的回滚段中偷取（steal）过期的extent，加入当前回滚段，并使用第一个数据块。
5、如果offline状态的回滚段中没有expired extent，则从online状态的回滚段中偷取（steal）过期区加入到当前的回滚段中，并使用extent中的第一个数据块。
6、如果undo tablespace可以扩展，则扩展undo tablespace，并将新extent加入到当前的回滚段中，同时使用第一个数据块，此时undo所占的操作系统空间开始增加。
