Automatic Tuning of Undo Retention Common Issues (Doc ID 1579779.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.2 to 12.1.0.2 [Release 12.1]
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.4 [Release 10.2 to 11.2]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Information in this document applies to any platform.

PURPOSE

This document is intended to address the most popular and common issues with the Automatic Tuning of Undo Retention. Oracle Database automatically tunes the undo retention period based on how the undo tablespace is configured.  本文档旨在解决“Undo保留自动调整”中最流行和常见的问题。Oracle Database根据undo表空间的配置方式自动调整undo保留期。
o If the undo tablespace is configured with the AUTOEXTEND option, the database dynamically tunes the undo retention period to be somewhat longer than the longest-running active query on the system.  如果undo表空间配置了AUTOEXTEND选项，则数据库会动态调整undo保留期，使其比系统上运行时间最长的活动查询更长。
o If the undo tablespace is fixed size, the database dynamically tunes the undo retention period for the best possible retention for that tablespace size and the current system load. This best possible retention time is typically significantly greater than the duration of the longest-running active query.  如果undo表空间是固定大小的，则数据库会动态调整undo保留期，以达到该表空间大小和当前系统负载的最佳保留。通常，此最佳可能的保留时间明显大于运行时间最长的活动查询的持续时间

For more infomration, please visit the Oracle Documentation Guide found via the following link:
http://docs.oracle.com/cd/B28359_01/server.111/b28310/undo002.htm

TROUBLESHOOTING STEPS

Automatic Tuning of Undo Retention Feature  自动调整undo保留功能

Oracle 10g/11g and higher version automatically tunes undo retention to reduce the chances of "snapshot too old" errors during long-running queries.  In the event of any undo space constraints, the system will prioritize DML operations over undo retention. In such situations, the low threshold may not be achieved and tuned_undoretention can go below undo_retention. If the undo retention threshold must be guaranteed, even at the expense of DML operations, the RETENTION GUARANTEE clause can be set against the undo tablespace during or after creation.

Oracle 10g/11g和更高版本会自动调整undo保留，以减少长时间运行的查询中出现 "snapshot too old" 错误的机会。如果存在任何undo空间限制，则系统将优先于DML操作优先于undo保留。在这种情况下，可能无法达到低阈值，并且 tuned_undoretention 可能会低于 undo_retention 。如果必须保证undo保留阈值（即使以DML操作为代价），则可以在创建期间或创建后针对undo表空间设置RETENTION GUARANTEE子句

-- Set/Reset the undo low threshold.  -设置/重置undo下限阈值

ALTER SYSTEM SET UNDO_RETENTION = 900;

 

-- Guarantee the minimum threshold is maintained.  -确保维持最低阈值

ALTER TABLESPACE undotbs RETENTION GUARANTEE;

 

You can enable the guarantee option for the undo tablespace when it is created by either the CREATE DATABASE or CREATE UNDO TABLESPACE statement or at a later period using the ALTER TABLESPACE statement.

通过 CREATE DATABASE 或 CREATE UNDO TABLESPACE 语句创建undo表空间时，或者在以后使用 ALTER TABLESPACE 语句创建undo表空间时，可以启用担保选项

Thus, tuned_undoretention can be less than undo_retention specified in the parameter file.  

因此，tuned_undoretention 可以小于参数文件中指定的 undo_retention

Common Issues  常见问题

 1- Space Related Issues/ Undo Tablespace is Full  与空间相关的问题/Undo表空间已满

Many UNEXPIRED undo segments can be seen when selecting  from dba_undo_extents view, although no ORA-1555 or ORA-30036 errors are reported.

从 dba_undo_extents 视图中进行选择时，可以看到许多 UNEXPIRED undo段，尽管没有报告 ORA-1555 或 ORA-30036 错误

a. Expected behavior/ Concepts Misunderstanding:  预期的行为/概念误解

When the UNDO tablespace is created with NO AUTOEXTEND, the below allocation algorithm is being followed:

当使用 NO AUTOEXTEND 创建 UNDO 表空间时，将遵循以下分配算法

1. If the current extent has more free blocks then the next free block is allocated. 如果当前扩展区具有更多空闲块，则将分配下一个空闲块
2. Otherwise, if the next extent expired then wrap in the next extent and return the first block. .否则，如果下一个扩展区已过期，则包装下一个扩展区并返回第一个块
3. If the next extent is not expired then get space from the UNDO tablespace. If a free extent is available then allocate it to the undo segment and return the first block in the new extent. 如果下一个扩展区未过期，请从UNDO表空间获取空间。如果有可用的扩展区，则将其分配给undo段，并返回新扩展区中的第一个块
4. If there is no free extent available, then steal expired extents from offline undo segments. De-allocate the expired extent from the offline undo segment and add it to the undo segment. Return the first free block of the extent. 如果没有可用的扩展区，则从脱机撤消段中窃取过期的扩展区。从离线撤uhndo段中取消分配过期的扩展区，并将其添加到undo段中。返回范围的第一个空闲块
5. If no expired extents are available in offline undo segments, then steal from online undo segments and add the new extents to the current undo segment.  Return the first free block of the extent. 如果离线undo段中没有可用的扩展范围，则从在线undo段中窃取并将新的扩展区添加到当前undo段中。返回范围的第一个空闲块
6. Extend the file in the UNDO tablespace. If the file can be extended then add an extent to the current undo segment and then return the block. 在UNDO表空间中扩展文件。如果文件可以扩展，则将范围添加到当前undo段，然后返回该块
7. Tune down retention in decrements of 10% and steal extents that were unexpired, but now expired with respect to the lower retention value. 调低10％的保留率，并窃取尚未过期但现在就较低保留值而言已过期的范围
8. Steal unexpired extents from any offline undo segments.  从任何离线undo段中窃取未到期的扩展区
9. Try to reuse unexpired extents from own undo segment. If all extents are currently busy (they contains uncommitted information) go to the step 10. Otherwise, wrap into the next extent.  尝试重用自己的undo段中未到期的扩展区。如果当前所有扩展区都忙（它们包含未提交的信息），请转到步骤10。否则，请打包到下一个扩展区
10. Try to steal unexpired extents from any online undo segment.  尝试从任何在线undo段中窃取未到期的扩展区
11. If all the above fails then return ORA-30036 unable to extend segment by %s in undo tablespace '%s'  如果以上所有方法均失败，则返回 ORA-30036 unable to extend segment by %s in undo tablespace '%s'

For a fixed size UNDO tablespace (NO AUTOEXTEND), starting with 10.2, we provide max retention given the fixed undo space, which is set to a value based on the UNDO tablespace size.  

对于固定大小的UNDO表空间（NO AUTOEXTEND），从10.2开始，我们提供给定固定undo空间的最大保留，该值设置为基于UNDO表空间大小的值

This means that even if the undo_retention is set to a number of seconds (900 default), the fixed UNDO tablespace supports a bigger undo_retention time interval (e.g: 36 hours), based on the tablespace size, thing that makes the undo extents to be UNEXPIRED. But this doesn't indicate that there are no available undo extents when a transaction will be run in the database, as the UNEXPIRED undo segments will be reused.  

这意味着即使将undo_retention设置为秒数（默认值为900），固定的UNDO表空间也根据表空间的大小支持更大的undo_retention时间间隔（例如36小时），这会使undo范围成为意外 但是，这并不表示在数据库中运行事务时没有可用的undo范围，因为UNEXPIRED undo段将被重用

Here is a small test case for making it clearer:  这是一个使它更清晰的小测试用例
Before starting any transaction in the database:  在数据库中开始任何事务之前

SQL> select count(status) from dba_undo_extents where status = 'UNEXPIRED';
COUNT(STATUS)
-------------
463

SQL> select count(status) from dba_undo_extents where status = 'EXPIRED';
COUNT(STATUS)
-------------
20

SQL> select count(status) from dba_undo_extents where status = 'ACTIVE';
COUNT(STATUS)
-------------
21

Space available reported by dba_free_space:
SUM(BYTES)/(1024*1024) TABLESPACE_NAME
---------------------- ---------------------
      3                  UNDOTBS1
      58.4375            SYSAUX
      3                  USERS3
      4.3125             SYSTEM
      103.9375           USERS04

When the transactions run:
SUM(BYTES)/(1024*1024) TABLESPACE_NAME
---------------------- ----------------
      58.25              SYSAUX
      98                 USERS3
      4.3125             SYSTEM
      87.9375            USERS04

b. wrong calculation of the tuned undo retention value  调整后的undo保留值的错误计算

For DB version lower than 10.2.0.4  对于低于10.2.0.4的数据库版本

it is caused by Bug:5387030 - This bug only affects db version lower than 10.2.0.4

它是由Bug:5387030引起的-此错误仅影响低于10.2.0.4的数据库版本

To investigate the issue, check the following:  要调查此问题，请检查以下内容

1- Undo automatically managed by the database  Undo由数据库自动管理

SQL> show parameter undo_

 

2- Type of undo tablespace (fixed, auto extensible)  undo表空间的类型（固定的，可自动扩展的）

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).

3- Undo表空间的大小已经确定，以使其始终具有足够的空间来存储在 undo_retention 时间内生成的所有undo，并且正在使用的undo空间永远不会超过undo表空间警告警报阈值（有关查询到显示阈值）

4- The tablespace threshold alerts recommend that the DBA add more space to the undo tablespace:

4- 表空间阈值警报建议DBA向undo表空间添加更多空间

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:

5- Undo表空间使用中空间在某个时间点超出警告警报阈值。要查看警告警报百分比阈值，请发出

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:

要查看正在使用的（当前）undo表空间百分比

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;

To solve the issue, you can either apply patch:5387030 (This bug only affects db version lower than 10.2.0.4) OR use any of the following workarounds:

要解决此问题，您可以应用patch：5387030（此错误仅影响低于10.2.0.4的数据库版本），或使用以下任何变通办法：

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):

1- 在此类中设置undo表空间的每个数据文件的 AUTOEXTEND 和 MAXSIZE 属性。它们可以自动扩展并且 MAXSIZE 等于当前大小的方式（因此，undo表空间现在具有 AUTOEXTEND 属性，但不会自动扩展）

SQL> ALTER DATABASE DATAFILE '<datafile_flename>' AUTOEXTEND ON MAXSIZE <current_size>

2- Set the following instance parameter (Contact Oracle Support before setting it):

2- 设置以下实例参数（在设置之前，请联系Oracle Support）：

_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. Which means that you will loose all advantages in having automatic undo management and is not an ideal long term fix. 使用此设置，将不维护 V$UNDOSTAT（以及因此的 V$UNDOSTAT.TUNED_UNDORETENTION），并且使用的undo保留基于 UNDO_RETENTION 实例参数。这意味着您将失去使用自动undo管理的所有优势，而不是理想的长期解决方案。 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. 即使安装了补丁程序修复程序，在某些情况下自动调整的保留量仍会增加。该修补程序试图抑制自动调整的积极程度。在某些环境中，可能需要选项2和3来避免这种激进的增长

For DB version 12.2 or higher and has Local Undo Mode enabled  对于数据库版本12.2或更高版本，并且启用了本地Undo模式

It is probably caused by bug 27543971, check note 27543971.8 for details 它可能是由bug 27543971引起的，有关详细信息，请参阅note 27543971.8

2- Undo Remains Unexpired and TUNED_UNDORETENTION is high  Undo保持未过期且TUNED_UNDORETENTION高

This matches Bug 9650380 where WRH$_UNDOSTAT table shows that TUNED_UNDORETENTION remains high based on previous workload after restarting the instance.  

这与 Bug 965038 0匹配，其中 WRH$_UNDOSTAT 表显示重新启动实例后，基于先前的工作量，TUNED_UNDORETENTION仍然很高

Bug 9650380 is closed as duplicate of Bug 9681444. It is caused by heavy undo generation right before an instance shutdown influencing the calculation of the tuned undo retention after instance startup. 

Bug 9650380 已作为 Bug 9681444 的重复副本被关闭。这是由于实例关闭之前大量的undo生成引起的，从而影响了实例启动后调整后的undo保留的计算

Possible workarounds for this issue are: 该问题的可能解决方法是

1) disable automatic tuning of undo by setting _undo_autotune=false (Contact Support before setting this parameter)
1) 通过设置_undo_autotune = false来禁用undo自动调整（在设置此参数之前，请联系支持人员）
This option requires manual tuning of the UNDO_RETENTION instance parameter to avoid ORA-1555 errors.
此选项需要手动调整UNDO_RETENTION实例参数以避免ORA-1555错误
2) turn on autoextensibility of the undo tablespace datafiles and set the MAXSIZE to the actual size of the all the datafiles of the undo tablespace, or set _smu_debug_mode=33554432.
2) 打开undo表空间数据文件的自动扩展性，并将MAXSIZE设置为undo表空间的所有数据文件的实际大小，或者设置_smu_debug_mode = 33554432
This option allows tuned undo retention, but bases the calculation on MAXQUERYLEN instead of the free space in the undo tablespace. This option also requires a sensible value for UNDO_RETENTION being set.
此选项允许调整的undo保留，但计算基于MAXQUERYLEN而不是undo表空间中的可用空间。此选项还需要为UNDO_RETENTION设置一个合理的
WARNING: do NOT set MAXSIZE > actual size! Otherwise the algorithm to calculate the tuned undo will again work based on the free space.
警告：请勿设置MAXSIZE>实际尺寸！否则，用于计算已调整undo的算法将再次基于可用空间工作
3) allocate more space to the undo tablespace and/or reduce the threshold level used for computation of the tuned undo retention value.
3) 将更多空间分配给undo表空间和/或减少用于计算调整后的undo保留值的阈值级别
You can control the extra space available for undo growth using the tablespace warning threshold:

您可以使用表空间警告阈值来控制可用于还原增长的额外空间

begin
DBMS_SERVER_ALERT.SET_THRESHOLD(
metrics_id => dbms_server_alert.tablespace_pct_full,
warning_operator => dbms_server_alert.operator_ge,
warning_value => '50', /* <<<<<<<<<<<<<<<<<<<<<<<< */
critical_operator => dbms_server_alert.operator_ge,
critical_value => '90',
observation_period => 1,
consecutive_occurrences => 1,
instance_name => NULL,
object_type => dbms_server_alert.object_type_tablespace,
object_name => 'UNDOTBS1');
end;
/

The above example provides more headroom for undo by setting the warning threshold to 50% of the tablespace size, thereby letting the tuned undo retention algorithm use 50% - 10% = 40% of the tablespace  

上面的示例通过将警告阈值设置为表空间大小的50％，为undo提供了更多的空间，从而使调整后的undo保留算法将表空间大小的50％-10％= 40％

size for its calculations. By default the algorithm uses 70% of the undo tablespace in the tuned undo retention calculation, leaving 30% headroom.

用于其计算。默认情况下，该算法在调整后的undo保留计算中使用undo表空间的70％，保留30％的净空

4) set the _first_spare_parameter (depending on version, check note 742035.1 for more details) or _highthreshold_undoretention (depending on version, check note 742035.1 for more details) instance parameter to a value limiting the tuned undo retention value. See Note 742035.1 for more details.

4) 将 _first_spare_parameter（取决于版本，请参见 note 742035.1，以获取更多详细信息）或 _highthreshold_undoretention（取决于版本，请参见 note 742035.1 ，以获取更多详细信息）实例参数为限制已调整的undo保留值的值。有关更多详细信息，请参见 Note 742035.1

If this value is set too high, you still will encounter problems with tuned undo retention. If this value is set too low, ORA-1555 errors are bound to happen.

如果此值设置得太高，您仍将在调整undo保留上遇到问题。如果此值设置得太低，则肯定会发生ORA-1555错误。

Next to this, monitor the ACTIVEBLKS + UNEXPIREDBLKS values in V$UNDOSTAT to be sure that not a too large portion of the undo tablespace is allocated by these block types. Otherwise stealing of undo blocks will occur which might again result in ORA-1555 errors. If these blocks take up a too high percentage of the blocks of the undo tablespace, consider adding more space to the tablespace, or tune down the undo retention.

下一步，监视 V$UNDOSTAT 中的 ACTIVEBLKS + UNEXPIREDBLKS 值，以确保这些块类型分配的undo表空间没有太大。否则将窃取undo块，这可能再次导致ORA-1555错误。如果这些块在undo表空间的块中占的比例太高，请考虑向表空间添加更多空间，或调低undo保留。

When available, download Patch 9681444 to resolve this issue.

如果可用，请下载补丁9681444以解决此问题。

Further Diagnostics  进一步诊断

If none of the above addressed your issue, please feel free to log an SR with Oracle Support providing the following information:

如果上述方法都不能解决您的问题，请随时通过Oracle支持提供以下信息来登录SR

1- Alert.log file

2- output of script in Doc 1579035.1.

3- Trace Files generated at the time of the issue

wrong calculation of the tuned undo retention value

REFERENCES

NOTE:1112431.1 - Undo Remains Unexpired When Using Non-autoextensible Datafiles For The Undo Tablespace
NOTE:413732.1 - Full UNDO Tablespace In 10gR2 and above
NOTE:1100313.1 - Tuned_UndoRetention Can be Less Than Undo_Retention in Init.ora
NOTE:311615.1 - Oracle 10G new feature - Automatic Undo Retention Tuning
NOTE:420525.1 - Automatic Tuning of Undo_retention Causes Space Problems