Undo Retention Tuning

Active:
Uncommitted undo information required if a user wants to roll back or if the transaction has
failed.
Uncommitted undo information is never overwritten.

Unexpired:
Committed undo information old undo information with an age that is less than the
current undo retention period

Expired:
expired undo information old committed information that is older the current undo retention
period is said to be expired and space is available to overwritten by new truncation retained
for consistent read and Oracle Flashback operations.

Here we found some important information about ‘’ how much consume active,
unexpired, expired uses undo tablespace”.

SQL> select tablespace_name tablespace, status, sum(bytes)/1024/1024

sum_in_mb, count(*) counts
from dba_undo_extents
group by tablespace_name, status order by 1,2;

SOMETNING IMPORTANT ABOUT UNDO:

Oracle Database automatically tunes the undo retention period based on how theundo
tablespace is configured.

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. However, this retention period may be
insufficient to accommodate Oracle Flashback operations. Oracle Flashback
operations resulting in snapshot too old errors are the indicator that you must
intervene to ensure that sufficient undo data is retained to support these
operations.
To better accommodate Oracle Flashback features, you can either set
the UNDO_RETENTION parameter to a value equal to the longest expected Oracle
Flashback operation, or you can change the undo tablespace to fixed size.

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.

If you decide to change the undo tablespace to fixed-size, you must choose a
tablespace size that is sufficiently large. If you choose an undo tablespace size
that is too small, the following two errors could occur:
DML could fail because there is not enough space to accommodate undo for
new transactions.
Long-running queries could fail with a snapshot too old error, which means that
there was insufficient undo data for read consistency.

Undo Retention:

• Oracle Database automatically tunes the undo retention period based on undo
tablespace size and system activity. You can specify a minimum undo retention
period (in seconds) by setting the undo_retention initialization parameter.
• The database makes its best effort to honour the specified minimum undo
retention period, provided that the undo tablespace has space available for new
transactions.
• When available space for new transactions becomes short, the database begins
to overwrite expired undo. If the undo tablespace has no space for new
transactions after all expired undo is overwritten, the database may begin
overwriting unexpired undo information.
• If any of this overwritten undo information is required for consistent read in a
current long-running query, the query could fail with the snapshot too old error
message.

The following points explain the exact impact of the undo_retention parameter on
undo retention:

• The undo_retention parameter is ignored for a fixed size undo tablespace. The
database may overwrite unexpired undo information when tablespace space
becomes low.
• For an undo tablespace with the auto-extend option enabled, the database
attempts to honour the minimum retention period specified by undo_retention.
 • When space is low, instead of overwriting unexpired undo information, the
tablespace auto-extends. If the max size clause is specified for an auto-extending
undo tablespace, when the maximum size is reached, the database may begin to
overwrite unexpired undo information.

Retention guarantee:
• To guarantee the success of long-running queries or oracle flashback operations,
you can enable retention guarantee. If retention guarantee is enabled, the
specified minimum undo retention is guaranteed; the database never overwrites
unexpired undo data even if it means that transactions fail due to lack of space in
the undo tablespace.
• If the retention guarantee is not enabled, the database can overwrite unexpired
undo when space is low, thus lowering the undo retention for the system. This
option is disabled by default.

Note:
• To guarantee the success of long-running queries or Oracle Flashback
operations, you can enable retention guarantee.

• If retention guarantee is enabled, then the specified minimum undo retention

is guaranteed; the database never overwrites unexpired undo data even if it
means that transactions fail due to lack of space in the undo tablespace. If
retention guarantee is not enabled, then the database can overwrite
unexpired undo when space is low, thus lowering the undo retention for the
system. This option is disabled by default.

⚠️ WARNING: Enabling retention guarantee can cause multiple DML operations to

fail.

• Use with caution. You enable retention guarantee by specifying the

RETENTION GUARANTEE clause for the undo tablespace when you create it
with either the CREATE DATABASE OF CREATE UNDO TABLESPACE
statement. Or, you can later specify this clause in an ALTER TABLESPACE
statement. You disable retention guarantee with the RETENTION
NOGUARANTEE clause.
 • You can use the DBA_TABLESPACES View to determine the retention
guarantee setting for the undo tablespace. A column named RETENTION
contains a value of GUARANTEE, NOGUARANTEE, Or NOT APPLY, Where
NOT APPLY is used for tablespaces other than the undo tablespace.

However it is worth to tune the following important parameters:

• The size of the UNDO tablespace

SELECT a.tablespace_name,
SIZEMB,
USAGEMB,
(SIZEMB - USAGEMB) FREEMB
FROM ( SELECT SUM (bytes) / 1024 / 1024 SIZEMB, b.tablespace_name
FROM dba_data_files a, dba_tablespaces b
WHERE a.tablespace_name = b.tablespace_name AND b.contents like 'UNDO'
GROUP BY b.tablespace_name) a,
( SELECT c.tablespace_name, SUM (bytes) / 1024 / 1024 USAGEMB
FROM DBA_UNDO_EXTENTS c
WHERE status <> 'EXPIRED'
GROUP BY c.tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name;
 • The UNDO_RETENTION parameter
SQL > show parameter undo;

Here the UNDO_RETENTION is 900. second which is default by oracle.

• We can change UNDO_RETENTION parameter dynamically but this is not
recommended by oracle.

Reset the undo low threshold.

ALTER SYSTEM SET UNDO_RETENTION = 2400;

• And set the NOGUARANTEE with GUARANTEE but this is also not recommended by
oracle.
Guarantee the minimum threshold is maintained.

ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

SQL> SELECT tablespace_name, retention FROM dba_tablespaces;

TABLESPACE_NAME RETENTION
------------------------------ -----------
SYSTEM NOT APPLY
UNDOTBS1 GUARANTEE
SYSAUX NOT APPLY
TEMP NOT APPLY
USERS NOT APPLY
Switch back to the default mode.
• automatically tunes undo retention to reduce the chances of “snapshot too
old” errors during long-running queries.

ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;

TABLESPACE_NAME RETENTION
------------------------------ -----------
SYSTEM NOT APPLY
UNDOTBS1 NOGUARANTEE
SYSAUX NOT APPLY
TEMP NOT APPLY
USERS NOT APPLY

Check undo usage by User or schema:

select u.tablespace_name tablespace, s.username, u.status, sum(u.bytes)/1024/1024 sum_in_mb,

count(u.segment_name) seg_cnts

from dba_undo_extents u, v$transaction t , v$session s

where u.segment_name = '&SCHEMA_NAME' || t.xidusn || '$' and t.addr = s.taddr

group by u.tablespace_name, s.username, u.status order by 1,2,3;