Oracle 11gR2 Database UNDO tablespace usage remains high

Oracle 11gR2 Database UNDO tablespace usage remains 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.

To put it simply, when the data file corresponding to the UNDO tablespace is not automatically extended and the UNDO tablespace is relatively 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 = '<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 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 = '<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 (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

This article was originally used to solve the bug in 10gR2, but it also applies in 11gR2, indicating that this bug exists in 11gR2. The article provides three solutions:

1) Adjust the data file corresponding to the UNDO tablespace to automatically expand and set a maximum value for it.
SQL> ALTER DATABASE DATAFILE '<datafile_flename> 'autoextend ON MAXSIZE <current_size>

The customer solved the problem in this way. After adjustment, the space was quickly released, V $ UNDOSTAT. the value of TUNED_UNDORETENTION decreases immediately, which is exactly the same as described in the previous article. When the data file corresponding to the UNDO tablespace is automatically expanded, V $ UNDOSTAT. the calculation of the TUNED_UNDORETENTION value does not depend on the percentage of the UNDO tablespace (the UNDO tablespace itself is large ).

2) Set _ smu_debug_mode to hide the parameter.
_ Smu_debug_mode = 33554432
We have explained this parameter before and verify it again here.

3). Set the _ undo_autotune hidden parameter.
_ Undo_autotune = false
The previous two methods did not disable Oracle's UNDO automatic RETENTION function. When _ undo_autotune is set to false, the function of automatic undo retention adjustment is completely disabled, the RETENTION time of UNDO depends on the UNDO_RETENTION value of the initialization parameter. The default value is 900 seconds.

Any of the above three methods can solve this problem.

This article is a helpful supplement to my other article: monitoring and managing the use of Oracle UNDO tablespaces:

Many of the knowledge points we learned may be forgotten over a period of time, but we can easily remember them through specific cases.

-- End --

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

Undo tablespace loss caused by rman backup and recovery

About Oracle releasing over-used undo tablespace

Oracle undo

Oracle undo image data exploration

Oracle ROLLBACK and undo)

Installing Oracle 12C in Linux-6-64

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian

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