Skip to Main Content

Breadcrumb

May 4th

Question and Answer

Connor McDonald

Thanks for the question, NILESH.

Asked: May 26, 2017 - 2:13 pm UTC

Last updated: May 27, 2017 - 7:01 am UTC

Version: 11g

Viewed 1000+ times

You Asked

Hi,

I have One undo Table space with 4 undo datafiles in my production database Oracle 11g and standby db. Each data file size is 30gb but uses only 1gb. so can i resize (shrink) all data files without downtime. please reply me with description and commands.

with LiveSQL Test Case:

and Connor said...

Check MOS note 268870.1, some of which is below

How to Shrink the datafile of Undo Tablespace (Doc ID 268870.1) To BottomTo Bottom 

GOAL

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 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 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.

SOLUTION

The steps to accomplish the goal are:

Create a new undo tablespace with a smaller size:
SQL> create undo tablespace UNDO_RBS1 datafile 'undorbs1.dbf' size <new size>;
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;
Drop the old undo 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.    Also be aware that on some platforms, disk space is not freed to the OS until the database is restarted.  The disk space will remain "allocated" from the OS perspective until the database restart.


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/tablespace is bigger. That said, it is important to monitor systems (e.g. with StatsPack) and watch for environment-specific issues.



Is this answer out of date? If it is, please let us know via a Comment