Oracle 11gR2 Database UNDO表空间使用率居高不下-转载

客户的数据库是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:
   
   SQL> SELECT
            ((SELECT (NVL(SUM(bytes),0))
              FROM dba_undo_extents 
              WHERE tablespace_name='<undo_tablespace_name>' 
              AND status IN ('ACTIVE','UNEXPIRED')) * 100)/         
            (SELECT SUM(bytes) 
             FROM dba_data_files 
             WHERE tablespace_name='<undo_tablespace_name>') 
            "PCT_INUSE" 
        FROM dual;

Cause

The cause of this problem has been identified in:
Bug:5387030 - AUTOMATIC TUNING OF UNDO_RETENTION CAUSING SPACE PROBLEMS

It is caused by a wrong calculation of the tuned undo retention value.

Bug:5387030 is fixed in RDBMS 11.1.

Solution

To implement a solution for Bug:5387030, please execute any of the below alternative solutions:

• Upgrade to 11.1 in which Bug:5387030 is fixed
  
  OR

• Apply patchset release 10.2.0.4 or higher in which Bug:5387030 is fixed.
  
  OR

• Download and apply interim Patch:5387030, if available for your platform and RDBMS release. To check for conflicting patches, please use the MOS Patch Planner Tool. If no patch is available, file a Service Request through My Oracle Support for your specific Oracle version and platform.
  
  OR

• Use any of the following workarounds:
  
  1. Set the AUTOEXTEND and MAXSIZE attributes of each datafile of the undo tablespace in such a way that they are autoextensible and the MAXSIZE is equal to the current size (so the undo tablespace now has the AUTOEXTEND attribute but does not autoextend):
     
     SQL> ALTER DATABASE DATAFILE '<datafile_flename>' AUTOEXTEND ON MAXSIZE<current_size>
     
     With this setting, V$UNDOSTAT.TUNED_UNDORETENTION is not calculated based on a percentage of the undo tablespace size. Instead it is set to the maximum of (MAXQUERYLEN secs + 300) and UNDO_RETENTION.
  2. Set the following instance parameter:
     
     _smu_debug_mode=33554432
     
     With this setting, V$UNDOSTAT.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.
  3. Set the following instance parameter:
     
     _undo_autotune = false
     
     With this setting, V$UNDOSTAT (and therefore V$UNDOSTAT.TUNED_UNDORETENTION) is not maintained and the undo retention used is based on the UNDO_RETENTION instance parameter.
     
     
     NOTE: This means you loose all advantages in having automatic undo management and is not an ideal long term fix.
  
  
  NOTE: Even with the patch fix installed, the autotuned retention can still grow under certain circumstances. The fix attempts to throttle back how aggressive that autotuning will be. Options 2 and 3 may be needed to get around this aggressive growth in some environments.

References

BUG:5387030 - AUTOMATIC TUNING OF UNDO_RETENTION CAUSING SPACE PROBLEMS
NOTE:413732.1 - Full UNDO Tablespace In 10gR2 and above


   这篇文章本来是用来解决10gR2中的bug，但是在11gR2中同样适用，说明在11gR2中同样存在该bug。在文章提供了3种解决方案：

1).将UNDO表空间对应的数据文件调整为自动扩展，并为其设定一个最大值。
SQL> ALTER DATABASE DATAFILE '<datafile_flename>' AUTOEXTEND ON MAXSIZE <current_size>

   客户正是通过这种方式解决了问题，调整之后空间很快得到释放，V$UNDOSTAT.TUNED_UNDORETENTION值立即变小，这和文章前面的解释是完全吻合的，当UNDO表空间对应的数据文件是自动扩展的，那么V$UNDOSTAT.TUNED_UNDORETENTION值的计算就不再依赖于UNDO表空间的百分比（UNDO表空间本身较大）。

2).设置_smu_debug_mode隐藏参数。
_smu_debug_mode=33554432
   前面我们已经对这个参数进行了解释，这里再次验证。

3).设置_undo_autotune隐藏参数。
_undo_autotune = false
   前面的两种方法没有关闭Oracle的UNDO自动调整RETENTION的功能，将_undo_autotune设置为false，就彻底关闭了自动调整UNDO RETENTION的功能，那么UNDO的RETENTION时间完全依赖于初始化参数UNDO_RETENTION的值，默认值为900秒。

   以上三种方法的任意一种方法都可以解决客户面临的该问题。

    这篇文章是对我另一篇文章有益的补充：《监控和管理Oracle UNDO表空间的使用》：http://blog.itpub.net/23135684/viewspace-1065601/

    我们学习的很多知识点过一段时间都可能忘记，但通过具体的案例我们更容易的记住。
   
--end--

转载：http://blog.itpub.net/23135684/viewspace-1406011/