Oracle11gR2DatabaseUNDO table space usage remains high

The customer's database is a standalone database of OracleDatabase11.2.0.3.0forAIX6.164bit. The customer queries DBA_FREE_SPACE and finds that the UNDO tablespace usage is as high

The customer's Database is a standalone Database of Oracle Database 11.2.0.3.0 for AIX 6.1 64bit. The customer queries DBA_FREE_SPACE and finds that the UNDO tablespace usage is as high

The customer's Database is a standalone Database of Oracle Database 11.2.0.3.0 for AIX 6.1 64bit. The customer queries DBA_FREE_SPACE and finds that the UNDO tablespace usage is as high as 98% or above. The customer's UNDO tablespace has been manually extended to 25 GB and has been increasing. In order to release the UNDO tablespace in a timely manner, the automatic expansion of all data files corresponding to the UNDO tablespace is disabled. Query DBA_UNDO_EXTENTS and find that there is no active extent in the UNDO tablespace. UNEXPIRED accounts for 60% of the total space, and 30% is EXPIRED, but Oracle does not release the space in time.

The customer's UNDO tablespace is not set to the GUARANTEE mode. Therefore, based on our knowledge, we understand that EXPIRED and UNEXPIRED In the UNDO tablespace may be reused, however, the usage of such a high UNDO tablespace seems unreliable.

Although UNDO_RETENTION and other parameters are set in the initialization parameters, from Oracle 10gR2, the automatic adjustment function of the UNDO tablespace is enabled by default in Oracle to find V $ UNDOSTAT. TUNED_UNDORETENTION found that the value was automatically adjusted to more than 3500 minutes in the recent period. That is to say, the data in the UNDO tablespace must be retained for nearly three days and will expire because the data has not expired for such a long period, the tablespace is large enough to ensure that the space consistency of the UNDO tablespace is not released. At the same time, an explanation below Oracle is also found:

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.

Simply put, when the data file corresponding to the UNDO tablespace is not automatically extended and the UNDO tablespace is large, the value of tuned_undoretention is calculated based on the percentage of the UNDO tablespace size, in some cases, the value of tuned_undoretention is adjusted to a very large value.

Solution: If _ smu_debug_mode = 33554432 is set, the automatic undo retention adjustment function of Oracle is still enabled, but the tuned_undoretention calculation is based on MAXQUERYLEN secs + 300, instead of calculating the percentage of the UNDO tablespace size, this can avoid a particularly large value in TUNED_UNTORETENTION.

The above content is taken from FAQ-Automatic Undo Management (AUM)/System Managed Undo (SMU) (Doc ID 461480.1).

We also refer to another article:

Automatic Tuning of Undo_retention Causes Space Problems (Doc ID 420525.1)

In this Document

Symptoms

Cause

Solution

References

Applies:
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:
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 =' '

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 adds more space to the undo tablespace:

SQL> SELECT creation_time, metric_value, message_type, reason, suggested_action
FROM dba_outstanding_alerts
WHERE object_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 =' ';

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 =' '
AND status IN ('active', 'unexpired') * 100 )/
(Select sum (bytes)
FROM dba_data_files
WHERE 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.