Initialization ParameterUNDO

UNDO_RETENTION, How and Why

UNDO_RETENTION

At times, you may find out or feel that UNDO_RETENTION is useless at all. Raising the number of seconds cannot resolve ORA-01555. This is true under some specific conditions. Here I quote the requisites from the official document below:

Fix-sized Undo Tablespace

The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace. The database always tunes the undo retention period for the best possible retention, based on system activity and undo tablespace size.

Autoextend Undo Tablespace

For an undo tablespace with the AUTOEXTEND option enabled, the database attempts to honor the minimum retention period specified by UNDO_RETENTION. When space is low, instead of overwriting unexpired undo information, the tablespace auto-extends. If the MAXSIZE clause is specified for an auto-extending undo tablespace, when the maximum size is reached, the database may begin to overwrite unexpired undo information. The UNDOTBS1 tablespace that is automatically created by DBCA is auto-extending.

Source: Oracle Database 12c: About the Undo Retention Period

Immediate Cure

In other words, if UNDO is automatically extending space a lot more than you expected, you can do nothing until it reaches its maximum size or you can do something like the following.

In that moment, I believe that most of undo segments are not ACTIVE, they are just UNEXPIRED. Meanwhile, SMON is trying to honor UNDO_RETENTION, so automatically extending UNDO space is its first choice.

If you don’t want it to extend space any longer, an immediate cure is to set a smaller UNDO_RETENTION within memory scope, just temporarily. After that, most of UNEXPIRED undo segments become EXPIRED, SMON starts to reclaim space and the size of UNDO tablespace stops growing.

Further reading: How to Check UNDO Tablespace Usage

For seeking appropriate UNDO_RETENTION, you can use Oracle supplied functions like the followings:

SQL> select dbms_undo_adv.best_possible_retention(sysdate-7, sysdate) UNDO_RETENTION from dual;

UNDO_RETENTION
--------------
       1583948

SQL> select dbms_undo_adv.longest_query(sysdate-7, sysdate) UNDO_RETENTION from dual;

UNDO_RETENTION
--------------
          7182

SQL> select dbms_undo_adv.required_retention(sysdate-7, sysdate) UNDO_RETENTION from dual;

UNDO_RETENTION
--------------
          7182

SQL> select dbms_undo_adv.rbu_migration(sysdate-7, sysdate) UNDO_RETENTION from dual;

UNDO_RETENTION
--------------
          1600

In the above, I queried the possible values of UNDO_RETENTION for the last 7 days. Please note that, one instance would return different values from the other instance in a RAC system. This is because different instances use different UNDO tablespace.

UNDO_RETENTION GUARANTEE

Here I make a matrix to show how space types correlate with RETENTION GUARANTEE. Let’s see how UNDO_RETENTION changes under different conditions.

NOGUARANTEEGUARANTEE
Fixed-SizedIs ignoredIs guaranteed
until no free space is left
AutoextendIs honoredIs guaranteed
until MAXSIZE is reached

As you can see, UNDO_RETENTION highly depends on the state of space management.

Leave a Reply

Your email address will not be published. Required fields are marked *