pat98's always & forever

* Goal
-----------------------------------------------------------------------------------------------------
Your production database has bi-annual or annual purging programs which generate huge redo. Due to this requirement, your undo tablespace grows rapidly and occupies most of the space on file system.
The purging process is run only few times a year. So would not like to keep the huge undo datafile in your database throughout the year. You don't want to buy additional disks unnecessarily.

You have created an undo tablespace with datafiles as AUTOEXTEND ON MAXSIZE UNLIMITED to avoid Error: ORA 1651 : unable to extend save undo segment by <num> in tablespace <name>.

You have tried "alter database datafile .. resize" which always fails with Error: ORA 3297 : file contains <num> blocks of data beyond requested RESIZE value.

You want to shrink the datafile to utilize the disk space for other tablespaces or other purposes.
* Solution
-----------------------------------------------------------------------------------------------------
-- Create new undo tablespace with smaller size.
SQL> create undo tablespace UNDO_RBS1 datafile 'undorbs1.dbf' size 100m;

-- Set new tablespace as undo_tablespace
SQL> alter system set undo_tablespace=undo_rbs1;

-- Drop the old tablespace.
SQL> drop tablespace undo_rbs0 including contents.

NOTE: Dropping the old tablespace may give ORA-30013 : undo tablespace '%s' is currently in use. This error indicates you must wait for the undo tablespace to become unavailable. In other words, you must wait for existing transaction to commit or rollback.

Points to Consider:

-  The value for undo_retention also has a role in growth of undo tablespace. If there is no way to get the undo space for a new transaction, then the undo space (retention) will be reused. But, if the datafiles for undo tablespace are set to auto extensible, it will not reuse the space. In such scenarios new transaction will allocate a space and your undo tablespace will start growing.

-  Is big really bad?  Overhead on larger file/tablespaces can theoretically impact the database and the OS.  With a small file, the OS would have to do minimal I/O.  Oracle would be able to cache the whole file and there would be less segments to manage.  With AUM you get bitmapped files and all its (space management) performance benefits-- (number of) undo segments are automatically managed and are not related to the size of the tablespace.  With the bigger file/tablespace you will have other overhead--e.g. backup will take longer--but as far as the undo management there should be no performance impact just because the file/tbs is bigger.  That said, it is important to monitor systems (e.g. with statspack) and watch for environment-specific issues.

ReferencesNote 135090.1 - Managing Rollback/Undo Segments in AUM (Automatic Undo Management)
ErrorsORA-30013 undo tablespace '%s' is currently in use