Your production database has semiannual or annual purging programs which generate huge redo. Due to this requirement, your undo tablespace grows rapidly and occupies most of the space on the file system. The purging process is run only a 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 the 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.
The Solution
The steps to accomplish the goal are:
1. Create a new undo tablespace with a smaller size:
SQL> create undo tablespace UNDO_RBS1 datafile 'undorbs1.dbf' size [new size];
2. Set the new tablespace as the undo tablespace to be used: (Note: If Data Guard Managed configuration is used, the below parameter modification needs to executed on any physical standbys serviced by this production database):
SQL> alter system set undo_tablespace=undo_rbs1;
3. Drop the old undo tablespace:
SQL> drop tablespace undo_rbs0 including contents;
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, a new transaction will allocate 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 fewer 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/tablespace is bigger. That said, it is important to monitor systems (e.g. with StatsPack) and watch for environment-specific issues.