客户的数据库是Oracle Database 11.2.0.3.0 for AIX 6.1 64bit的单机数据库。客户查询DBA_FREE_SPACE发现UNDO表空间的使用率高达98%以上。客户的UNDO表空间已经手动扩展到了25GB，且一直在增加，为了UNDO表空间能及时的被释放，UNDO表空间对应的所有数据文件自动扩展都被关闭。查询DBA_UNDO_EXTENTS发现在UNDO表空间中当前没有ACTIVE的EXTENT存在，UNEXPIRED的占到总空间的60%，有30%是EXPIRED，但Oracle并没有及时的释放这些空间。
客户的UNDO表空间并没有设置成GUARANTEE模式，所以根据我们的知识都明白UNDO表空间中的EXPIRED和UNEXPIRED都是可能被重用的，但是这么高的UNDO表空间使用率看着让人不踏实。
虽然我们在初始化参数中设置了UNDO_RETENTION等参数，但从Oracle 10gR2开始，默认Oracle都开启了UNDO表空间的自动调整功能，查找V$UNDOSTAT.TUNED_UNDORETENTION发现最近一段时间该值都被自动调整到了3500多分钟，也就是说UNDO表空间中的数据要保留接近3天才会过期，正是因为这么长的数据未过期时间，且表空间又足够的大，才导致了UNDO表空间的空间一致未被释放，同时也找到了Oracle下面的一段解释：
Why TUNED_UNDORETENTION is calculated so high making undo space grow fast ?
When non-autoextensible undo space is used, tuned_undoretention is calculated based on a percentage of the undo tablespace size. In some cases especially with large undo tablespace, This will make it to be calculated so large.
To fix this behaviour, Set the following instance parameter:
_smu_debug_mode=33554432
With this setting, TUNED_UNDORETENTION is not calculated based on a percentage of the fixed size undo tablespace. Instead it is set to the maximum of (MAXQUERYLEN secs + 300) and UNDO_RETENTION.
简单的说，就是当UNDO表空间对应的数据文件非自动扩展，且UNDO表空间又比较大的时候，tuned_undoretention的值是根据UNDO表空间大小的百分比来计算的，在一些情况下会将tuned_undoretention的值调整得特别大。
解决办法，如果设置_smu_debug_mode=33554432，那么Oracle的UNDO RETENTION自动调整功能依然被开启，但是计算tuned_undoretention是根据MAXQUERYLEN secs +300来计算，而不是根据UNDO表空间大小的百分比来计算，这样就可以避免TUNED_UNTORETENTION出现特别大的值。
以上内容摘自：《FAQ – Automatic Undo Management (AUM) / System Managed Undo (SMU) (Doc ID 461480.1)》。
同样我们还参考了另一篇文章：
Automatic Tuning of Undo_retention Causes Space Problems (Doc ID 420525.1)
In this Document
Symptoms
Cause
Solution
References
Applies to:
Oracle Database - Enterprise Edition - Version 10.2.0.4 to 10.2.0.4 [Release 10.2]
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 -- fixed by patchset 10.2.0.4 and no issues on this at 11g
*** Checked for currency: 13-SEP-2012 ***
Symptoms
You have verified that Document 413732.1 is not applicable and the problem is not a misunderstanding in the way EXPIRED/UNEXPIRED are used and reused over time.
Look for:
1. Whether the undo is automatically managed by the database by checking the following instance parameter:
UNDO_MANAGEMENT=AUTO
2. Whether the undo tablespace is fixed in size:
SQL> SELECT autoextensible
FROM dba_data_files
WHERE tablespace_name='<UNDO_TABLESPACE_NAME>'
This returns "NO" for all the undo tablespace datafiles.
3. The undo tablespace is already sized such that it always has more than enough space to store all the undo generated within the undo_retention time, and the in-use undo space never exceeds the undo tablespace warning alert threshold (see below for the query to show the thresholds).
4. The tablespace threshold alerts recommend that the DBA add more space to the undo tablespace:
SQL> SELECT creation_time, metric_value, message_type, reason, suggested_action
FROM dba_outstanding_alerts
WHERE object_name='<UNDO_TABLESPACE_NAME>';
This returns a suggested action of: "Add space to the tablespace".
Or,
This recommendation has been reported in the past but the condition has now cleared:
SQL> SELECT creation_time, metric_value, message_type, reason, suggested_action, resolution
FROM dba_alert_history
WHERE object_name='<UNDO_TABLESPACE_NAME>';
5. The undo tablespace in-use space exceeded the warning alert threshold at some point in time. To see the warning alert percentage threshold, issue:
SQL> SELECT object_type, object_name, warning_value, critical_value
FROM dba_thresholds
WHERE object_type='TABLESPACE';
To see the (current) undo tablespace percent of space in use: