Oracle 9i has provided us with the AUTO UNDO management introducing new initialization parameters, new tablespace and its manageability by users

(1) UNDO_MANAGEMENT with values TRUE and FALSE
(2) UNDO_TABLESPACE where in the user can pass the name of the UNDO tablespace
(3) UNDO_RETENTION the period for which the data is to be retained in the undo tablespace. Default value is 900 seconds and max time is 2 ^ 32 –1. This demands proportionate increases in the size of the undo tablespace and EM Undo depending upon the rate of generation of undo at the database level.
(4) UNDO_SUPPRESS_ERRORS this has two values TRUE or FALSE and the default is TRUER which will be spitting error and alert messages in the alert log file at the background dump destination.

Oracle 10g

Oracle Database 10g automatically tune undo retention by collecting database use statistics and estimating undo capacity needs for the successful completion of the queries. You can set a low threshold value for the UNDO_RETENTION parameter so that the system retains the undo for at least the time specified in the parameter, provided that the current undo tablespace has enough space. Under space constraint conditions, the system may retain undo for a shorter duration than that specified by the low threshold value in order to allow DML operations to succeed.

Retention Guarantee

Oracle says

Oracle Database 10g let you guarantee undo retention. When you enable this option, the database never overwrites unexpired undo data. Undo data whose age is less than the undo retention period may not be made available by oracle.

The default option is DISABLED

This option is disabled by default, which means that the database can overwrite the unexpired undo data in order to avoid failure of DML operations if there is not enough free space left in the undo tablespace.

By enabling the guarantee option, you instruct the database not to overwrite unexpired undo data even if it means risking failure of currently active DML operations. Therefore, use caution when using this feature. A typical use of the guarantee option is when you want to ensure deterministic and predictable behavior of Flashback Query by guaranteeing the availability of the required undo data.

BEWARE of the space requirement.

You can enable the guarantee option by specifying the RETENTION GUARANTEE clause for the undo tablespace when either the CREATE DATABASE or CREATE UNDO TABLESPACE statement creates it. Or, you can later specify this clause in an ALTER TABLESPACE statement. You do not guarantee that unexpired undo is preserved if you specify the RETENTION NOGUARANTEE clause.

You can use the DBA_TABLESPACES view to determine the RETENTION setting for the undo tablespace. A column named RETENTION will contain a value on GUARANTEE, NOGUARANTEE, or NOT APPLY (used for tablespaces other than the undo tablespace).

Calculating the Space Requirements For Undo Retention

You can calculate space requirements manually using the following formula:

UndoSpace = UR * UPS + overhead
where:
UndoSpace is the number of undo blocks
UR is UNDO_RETENTION in seconds. This value should take into consideration long-running queries and any flashback requirements.

UPS is undo blocks for each second overhead is the small overhead for metadata (transaction tables, bitmaps, and so forth)

As an example, if UNDO_RETENTION is set to 6 hours, and the transaction rate (UPS) is 200 undo blocks for each second, with a 16K block size, the required undo space is computed as follows:

(6 * 3600 * 200 * 16K) = 65.8GBs

Using information in the V$UNDOSTAT view we can perform such computation. In the steady state, you can query the view to obtain the transaction rate. The overhead figure can also be obtained from the view.