ITPub博客

首页 > Linux操作系统 > Linux操作系统 > How to Shrink the datafile of Undo Tablespace

How to Shrink the datafile of Undo Tablespace

原创 Linux操作系统 作者:jesse_lui 时间:2011-09-10 11:52:55 0 删除 编辑
How to Shrink the datafile of Undo Tablespace [ID 268870.1]

  修改时间 17-AUG-2011     类型 HOWTO     状态 PUBLISHED  

In this Document
  Goal
  Solution
  References


Applies to:

Oracle Server - Standard Edition - Version: 9.2.0.7 to 11.2.0.2 - Release: 9.2 to 11.2
Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 11.2.0.2   [Release: 9.2 to 11.2]
Information in this document applies to any platform.

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 Error: ORA 1651 : unable to extend save undo segment by in tablespace .

You have tried "alter database datafile .. resize" which always fails with Error: ORA 3297 : file contains 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.    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/tbs is bigger.  That said, it is important to monitor systems (e.g. with statspack) and watch for environment-specific issues.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26104736/viewspace-707096/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-07-28

  • 博文量
    6
  • 访问量
    6586