Skip Headers

Oracle® Database Administrator's Guide
10g Release 1 (10.1)

Part Number B10739-01
Go to Documenta
tion Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master I ndex
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

10 Managing the Undo Tablespace

This chapter describes how to manage the undo tablespace, w hich stores information used to roll back changes to the Oracle Database. It contains the following topics:


See Also:

Part III, " Automated File and Storage Management " for information about creating an undo tablespace whose datafiles are both created and managed by the Oracle Database server.

What Is Undo?

Every Oracle Database must have a method of maintaining information that is used to roll back, or undo, changes to the datab ase. Such information consists of records of the actions of transactions, primarily before they are committed. These records are coll ectively referred to as undo.

Undo records are used to:

When a ROLLBACK statement is iss ued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, u ndo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistenc y by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.

Earlier releases of Oracle Database used rollback segments to store undo. Oracle9i introduced automatic undo managem ent, which simplifies undo space management by eliminating the complexities associated with rollback segment management. Oracle stron gly recommends that you use undo tablespace to manage undo rather than rollback segments.


See Also:

"Migration to Automatic Undo Man agement" for information on how to migrate to automatic undo management

Introduction to Automatic Undo Management

This section introduces the concepts of Automat ic Undo Management and discusses the following topics:

< a id="sthref1404" name="sthref1404">

Overview of Automatic Undo Ma nagement

In past releases, when you used the rollback segment method of manag ing undo space, you were said to be operating in the manual undo management mode. Now, you use the undo tablespace method, and you ar e said to be operating in the automatic undo management mode. You determine the mode at instance startup using the UNDO_MANAGEM ENT initialization parameter. The default value for this parameter is MANUAL. You set it to AUTO to enable automatic undo management.


Notes:

  • You cannot use both methods in the same database instance, although for migration purposes i t is possible, for example, to create undo tablespaces in a database that is using rollback segments, or to drop rollback segments in a database that is using undo tablespaces. However, you must shut down and restart your database in order to effect the switch to an other method of managing undo.

  • When operating in automatic undo management mode, any manual undo managem ent SQL statements are ignored and no error message is issued. For example, ALTER ROLLBACK SEGMENT statements will be ig nored.


The following initialization parameter setting causes the STARTUP command to start an instance in automatic undo management mode:

UNDO_M
ANAGEMENT = AUTO

An undo tablespace must be available, into which the database will store undo records. The default undo tablespace is created at database creation, or an undo tablespace can be created explicitly. The methods of creating an undo tablespa ce are explained in "Creating an Undo Tablespace"

When the instance starts up, the database automatica lly selects for use the first available undo tablespace. If there is no undo tablespace available, the instance starts, but uses the SYSTEM rollback segment for undo. This is not recommended in normal circumstances, and an alert message is written to th e alert file to warn that the system is running without an undo tablespace. ORA-01552 errors are issued for any attempts to write non -SYSTEM related undo to the SYSTEM rollback segment.

If the database contains multiple undo tablespa ces, you can optionally specify at startup that you want an Oracle Database instance to use a specific undo tablespace. This is done by setting the UNDO_TABLESPACE initial ization parameter. For example:

UNDO_TABLESPACE = undotbs_01

In this case, if you have not already created the undo tablespace (in this example, undotbs_01), the STARTUP command will fail. The UNDO_TABLESPACE parameter can be used to assign a specific undo tablespace to an instance in an Oracle Real Application Clust ers environment.

The following is a summary of the initialization parameters for auto matic undo management mode:

< /tr>
Initialization Parameter Description
UNDO_MANAGEMENT If AUTO, u se automatic undo management mode. If MANUAL, use manual undo management mode. The default is MANUAL.
UNDO_TABLESPACE An optional dynamic parameter specifying the name of an undo tablespace to use. This parameter should be used only when the database has multiple undo tablespaces and you want to direct the database instance to use a particular undo table space.
UNDO_RETENTION A dynamic parameter specifying the minimum length of time to retain undo. The default is 900 s econds. The setting of this parameter should take into account any flashback requirements of the system.

If the initialization parameter file contains parameters relating to manual undo managem ent, they are ignored.


See Also:

Oracle Database Reference for complete de scriptions of initialization parameters used in automatic undo management mode

Undo Retenti on

Committed undo information normally is lost when its undo space is overwritten by a newer transaction. However, for consistent read purposes, long-running queries sometimes require old undo information for undoing changes and producing older images of data blocks. The success of several Flashback features can also depend upon older undo information.

Automatic Tuning of Undo Retention

Oracle Database 10g automatically tunes 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 parame ter, 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.

In order to guara ntee the success of queries even at the price of compromising the success of DML operations, you can enable retention guarantee. The RETENTION GUARANTEE clause of the CREATE UNDO TABLESPACE and CREATE DATABASE statements ensure s that undo information is not overwritten. This option must be used with caution, because it can cause DML operations to fail if the undo tablespace is not big enough. However, with proper settings, long-running queries can complete without risk of receiving the "s napshot too old" message, and you can guarantee a time window in which the execution of Flashback features will succeed.

Setting the UNDO_RETENTION Initialization Parameter

The default val ue for the UNDO_RETENTION parameter is 900. Retention is specified in units of seconds. This parameter determines the lo w threshold value of undo retention. The system retains undo for at least the time specified in this parameter. The setting of this p arameter should account for any flashback requirements of the system.

You can set the UNDO_RETENTION parameter in itially in the initialization parameter file that is used by the STARTUP process:

UNDO_RET
ENTION = 1800

You can change the UNDO_RETENTION parameter value at any time using the ALTER SYSTEM statement:

ALTER SYSTEM SET UNDO_RETENTION = 2400

The effect of the UNDO_RETENTIO N parameter is immediate, but it can only be honored if the current undo tablespace has enough space. If an active transaction requires undo space and the undo tablespace does not have available space, then the system starts reusing unexpired undo space. This action can potentially cause some queries to fail with the "snapshot too old" message.

The amount of time for which undo is r etained for Oracle Database for the current undo tablespace can be obtained by querying the TUNED_UNDORETENTION column o f the V$UNDOSTAT dynamic performance view.

Automatic tuning of undo retention is not supported for LOBs. The RETENTION value for LOB columns is set to the value of the UNDO_RETENTION parameter.

Sizing the Undo Tablespace

You can size the undo tablespace appropriatel y either by using automatic extension of the undo tablespace or by manually estimating the space you will need for undo. This section discusses both methods.

Using Auto-Extensible Tablespaces

Oracle Database supports automatic extension of the undo tablespace to facilitate capacity planning of the undo tablespace in the production environment. When the system is first running in the production environment, you may be unsure of the space requirements of the undo tablespace. In th is case, you can enable automatic extension for datafiles of the undo tablespace so that they automatically increase in size when mor e space is needed. By combining automatic extension of the undo tablespace with automatically tuned undo retention, you can ensure th at long-running queries will succeed by guaranteeing the undo required for such queries.

After the system has stabilized and y ou are more familiar with undo space requirements, Oracle recommends that you set the maximum size of the tablespace to be slightly ( 10%) more than the current size of the undo tablespace.

Sizing Fixed-S ize Undo Tablespaces

If you have decided on a fixed-size undo tablespace, the Undo Advisor can help you estimate neede d capacity, and you can then calculate the amount of retention your system will need. You can access the Undo Advisor through Enterpr ise Manager or through the DBMS_ADVISOR PL/SQL package. Enterprise Manager is the preferred method of accessing the advi sor. For more information on using the Undo Advisor through EM, please refer to Oracle Database 2 Day DBA.

The Undo Advisor relies for its analysis on data collected in the Automati c Workload Repository (AWR). An adjustment to the collection interval and retention period for AWR statistics can affect the precisio n and the type of recommendations the advisor produces. Please refer to "Automatic Workload Repository" for additional information.

The Undo Advisor PL/SQL Interface

Oracle Database prov ides an Undo Advisor that provides advice on and helps automate the establishment of your undo environment. You activate the Undo Adv isor by creating an undo advisor task through the advisor framework. The following example creates an undo advisor task to evaluate t he undo tablespace. The name of the advisor is 'Undo Advisor'. The analysis is based on Automatic Workload Repository snapshots, whic h you must specify by setting parameters START_SNAPSHOT and END_SNAPSHOT. In the following example, the START_SNAPSHOT is "1" and END_SNAPSHOT is "2".

DECLARE
   tid    NUMBER;
   tnam
e  VARCHAR2(30);
   oid    NUMBER;
   BEGIN
   DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');
   DBMS_ADV
ISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
   DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid
);
   DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
   DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
   D
BMS_ADVISOR.execute_task(tname);
   end;
/

Once you have created the advisor task, you can view the output and recommendat ions in the Automatic Database Diagnostic Monitor in Enterprise Manager. This information is also available in the DBA_ADVISOR_ * data dictionary views.


See Als o:


Calculating the Space Requirements For Undo Retention

You can calculate space requirements manually using the following formula:

UndoSpace = UR * UPS + over
head

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.

    < /li>
  • 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 2 hours, and the transaction rate (UPS) is 200 undo blocks for each second, with a 4K block size, the required undo space is computed as follows :

(2 * 3600 * 200 * 4K) = 5.8GBs

Such computation can be performed by using information in the V$UNDOSTAT view. In the steady state, you can query the view to obtain the transaction rate. The overhead figure can also be obtained from the v iew.

Manag ing Undo Tablespaces

This section describes the various steps involved in undo tablespace management and contains the following sections:

Creating an Undo Tablespace

There are two methods of creating an undo tablespace. The first method creates the undo tablespace wh en the CREATE DATABASE statement is issued. This occurs when you are creating a new database, and the instance is starte d in automatic undo management mode (UNDO_MANAGEMENT = AUTO). The second method is used with an existing database. It us es the CREATE UNDO TABLESPACE statement.

You cannot create database objects in an undo tablespace. It is reserved for system-managed undo data.

Oracle Database enables you to create a single-file undo tablespace. Single-file, or bigfile, t ablespaces are discussed in "Bigfile Tablespaces".

Using CREAT E DATABASE to Create an Undo Tablespace

You can create a specific undo tablespace using the UNDO TABLESPACE clause of the CREATE DATABASE statement.

The following statement illustrates using the UNDO TABLESPACE clause in a CREATE DATABASE statement. The undo tablespace is named undotbs_01 and one datafile, /u01/oracle/rbdb1/undo0101.dbf, is allocated for it.

CREATE DATABASE rbdb1
     CONTROLFILE RE
USE
     .
     .
     .
     UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';

If the undo tablespac e cannot be created successfully during CREATE DATABASE, the entire CREATE DATABASE operation fails. You mu st clean up the database files, correct the error and retry the CREATE DATABASE operation.

The CREATE DATAB ASE statement also lets you create a single-file undo tablespace at database creation. This is discussed in "Supporting Bigfile Tablespaces During Database Creation".


See Also:

Oracle Database SQL Reference for the syntax for using the CREATE DATABASE statem ent to create an undo tablespace

Usi ng the CREATE UNDO TABLESPACE Statement

The CREATE UNDO TABLESPACE statement is the same as the CREATE TABLESPACE statement, but the UNDO keyword is specified. The databas e determines most of the attributes of the undo tablespace, but you can specify the DATAFILE clause.

This example creates the undotbs_02 undo tablespace:

CREATE UNDO TABLESPACE undotbs_02
     DATAFILE '
/u01/oracle/rbdb1/undo0201.dbf' SIZE 2M REUSE AUTOEXTEND ON;

You can create more than one undo tablespace, but only one o f them can be active at any one time.


S ee Also:

Oracle Database SQL Reference for the syntax for using the CREATE UNDO TABLESPACE statement to create an undo tablespa ce

Altering an Undo Tablespace

Undo tablespa ces are altered using the ALTER TABLESPACE statement. However, since most aspects of undo tablespaces are system managed , you need only be concerned with the following actions:

  • Adding a datafile

  • Renaming a datafile

  • Bringing a datafile online or taking it offline

  • Beginni ng or ending an open backup on a datafile

  • Enabling and disabling undo retention guarantee

These are also the only attributes you are permitted to alter.

If an undo tablespace runs out of space, or you want to prev ent it from doing so, you can add more files to it or resize existing datafiles.

The following example adds another datafile t o undo tablespace undotbs_01:

ALTER TABLESPACE undotbs_01
     ADD DATAFILE '/u01/oracle/rbdb1/undo0102
.dbf' AUTOEXTEND ON NEXT 1M 
         MAXSIZE UNLIMITED;

You can use the ALTER DATABASE ... DATAFILE stateme nt to resize or extend a datafile.

< /a>

Dropping an Undo Tablespace

Use the DROP TABLESPACE statement to drop an undo tablespace. The following example drops the undo tab lespace undotbs_01:

DROP TABLESPACE undotbs_01;

An undo tablespace can only be dropped if it is not currently used by any instance. If the undo tablespace contains any outstanding transactions (for example, a tr ansaction died but has not yet been recovered), the DROP TABLESPACE statement fails. However, since DROP TABLESPAC E drops an undo tablespace even if it contains unexpired undo information (within retention period), you must be careful not t o drop an undo tablespace if undo information is needed by some existing queries.

DROP TABLESPACE for undo tables paces behaves like DROP TABLESPACE ... INCLUDING CONTENTS. All contents of the undo tablespace are removed.


See Also:

Oracle Database SQL Reference for DROP TABLESPACE syntax

Switching Undo Tablespaces

You can switch from using one un do tablespace to another. Because the UNDO_TABLESPACE initialization parameter is a dynamic parameter, the ALTER S YSTEM SET statement can be used to assign a new undo tablespace.

The following statement switches to a new undo tablesp ace:

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

Assuming undotbs_01 is the current undo tablespace, after this command successfully executes, the instance uses undotbs_02 in place of undot bs_01 as its undo tablespace.

If any of the following conditions exist for the tablespace being switched to, an error i s reported and no switching occurs:

  • The tablespace does not exist

  • The table space is not an undo tablespace

  • The tablespace is already being used by another instance (in a RAC envir onment only)

The database is online while the switch operation is performed, and user transactions can be executed w hile this command is being executed. When the switch operation completes successfully, all transactions started after the switch oper ation began are assigned to transaction tables in the new undo tablespace.

The switch operation does not wait for transactions in the old undo tablespace to commit. If there are any pending transactions in the old undo tablespace, the old undo tablespace ente rs into a PENDING OFFLINE mode (status). In this mode, existing transactions can continue to execute, but undo records f or new user transactions cannot be stored in this undo tablespace.

An undo tablespace can exist in this PENDING OFFLINE< /code> mode, even after the switch operation completes successfully. A PENDING OFFLINE undo tablespace cannot be used by another instance, nor can it be dropped. Eventually, after all active transactions have com mitted, the undo tablespace automatically goes from the PENDING OFFLINE mode to the OFFLINE mode. From then on, the undo tablespace is available for other instances (in an Oracle Real Application Cluster environment).

If the paramete r value for UNDO TABLESPACE is set to '' (two single quotes), then the current undo tablespace is switched out and the n ext available undo tablespace is switched in. Use this statement with care, because if there is no undo tablespace available, the SYSTEM rollback segment is used. This causes ORA-01552 errors to be issued for any attempts to write non-SYSTEM related undo to the SYSTEM rollback segment.

The following example unassigns the current undo tablespace:

< pre xml:space="preserve">ALTER SYSTEM SET UNDO_TABLESPACE = '';

Es tablishing User Quotas for Undo Space

The Oracle Database Resource Manager ca n be used to establish user quotas for undo space. The Database Resource Manager directive UNDO_POOL allows DBAs to limi t the amount of undo space consumed by a group of users (resource consumer group).

You can specify an undo pool for each consu mer group. An undo pool controls the amount of total undo that can be generated by a consumer group. When the total undo generated by a consumer group exceeds its undo limit, the current UPDATE transaction generating the redo is terminated. No other mem bers of the consumer group can perform further updates until undo space is freed from the pool.

When no UNDO_POOL directive is explicitly defined, users are allowed unlimited undo space.

Monitoring the Undo Tablespace

This section lists views that are useful for viewing information about undo space in the automatic undo management mode and provide s some examples. In addition to views listed here, you can obtain information from the views available for viewing tablespace and dat afile information. Please refer to " Viewing Datafile Information" for information on getting infor mation about those views.

Oracle Database also provides proactive help in managing tablespace disk space use by alerting you w hen tablespaces run low on available space. Please refer to "Managing Space in Tablespaces " for in formation on how to set alert thresholds for the undo tablespace.

In addition to the proactive undo space alerts, Oracle Datab ase also provides alerts if your system has long-running queries that cause SNAPSHOT TOO OLD errors. To prevent excessiv e alerts, the long query alert is issued at most once every 24 hours. When the alert is generated, you can check the Undo Advisor Pag e of Enterprise Manager to get more information about the undo tablespace.

The following dynamic performance views are useful for obtaining space information about the undo tablespace:

View Description
V$UNDOSTAT Contains statistics for monitoring and tuning undo sp ace. Use this view to help estimate the amount of undo space required for the current workload. The database also uses this informati on to help tune undo usage in the system. This view is meaningful only in automatic undo management mode.
V$ROLLSTAT For automatic undo management mode, information reflects behavior of the undo segments in the undo tablespace
V$TRANSACTION Contains undo segment information< /td>
DBA_UNDO_EXTENTS Shows the status and size of each extent in the undo t ablespace.
WRH$_UNDOSTAT Contains statistical snapshots of V$UNDO STAT information. Please refer to Oracle Database 2 Day DBA for more information.
WRH$_ROLLSTAT Contain s statistical snapshots of V$ROLLSTAT information. Please refer to Oracle Database 2 Day DBA for more information.


See Also:

Oracle Database Reference for complete descriptions of the views used in automatic undo management mode

Flashback Features and Undo Space

Your Oracle Database includes severa l features that are based upon undo information and that allow administrators and users to access database information from a previou s point in time. These features are part of the overall flashback strategy incorporated into the database and include:

The retention period for undo information is an important factor for the successful execution of Flashback features. It determines how far back in time a database version can be established. Specifically, you must choose an undo retention interval that is long enough to enable users to construct a snapshot of the database for the oldest version of the database that they are interested in. For example, if an application requires that a version of the dat abase be available reflecting its content 12 hours previously, then UNDO_RETENTION must be set to 43200.

You migh t also want to guarantee that unexpired undo is not overwritten by specifying the RETENTION GUARANTEE clause fo r the undo tablespace as described in "Undo Retention".

Flashback Query

Using Oracle Flashback Query feature, users or applications can execute queries as of a previous time in the database. Application developers can use Flashback Query to design an application that allows users to c orrect their mistakes with minimal DBA intervention. You, as the DBA, need only configure the undo tablespace with an appropriate siz e and undo retention period. No further action on your part should be required.

The Oracle-supplied DBMS_FLASHBACK package implements Flashback Query at the session level. At the object level, Flashback Qu ery uses the AS OF clause of the SELECT statement to specify the previous point in time for which you wish to view data.


See Also:


Flashback Versions Query

The Flashback Version Query feature enables users to query the history of a given row. A SELECT state ment that specifies a VERSIONS clause returns individual versions of a row between two specified SCNs (system change num bers) or timestamps. The UNDO_RETENTION initialization parameter must be set to a value that is large enough to cover th e period of time specified in the VERSIONS clause. Otherwise, not all rows can be retrieved.

The VERSIONS clause can also be used in subqueries of DML and DDL statements.


See Also:


Flashback Transaction Query

Oracle Database provides a view, FLASHBACK_TRANSACTION_QUERY, that enables you to identify changes made by a particul ar transaction, or by all transactions issued within a specified period of time. One use for this view could be if a user finds, by u sing the Flashback Transaction Query feature, that a row value has been changed inappropriately. Querying the FLASHBACK_TRANSAC TION_QUERY view can provide specific details of the transaction or transactions that changed the row value.


See Also:

"Auditing Table Changes Using Flashback Transaction Query" for more information about using the Flashback Transaction Query fe ature

Flashback Table

The FLASHBACK TABLE statement lets users recover a table to a previous point in time. It provides a fast, online solution for recovering a table that has been accidentally modified or deleted by a user or applicat ion. The UNDO_RETENTION initialization parameter must be set to a value that is large enough to cover the period specifi ed in the FLASHBACK TABLE statement.


See Also:

"Recovering Tables Using the Flashback Table Feature" for more information about the FLASHBACK TABLE statement

Migration to Automatic Undo Management

If you are still using rollback segments to manage undo space, Oracle stro ngly recommends that you migrate your database to automatic undo management. Oracle Database provides a function that provides inform ation on how to size your new undo tablespace based on the configuration and usage of the rollback segments in your system. DBA privi leges are required to execute this function:

DECLARE
   utbsiz_in_MB NUMBER;
BEGIN
   utbsiz_in_MB ;= D
BMS_UNDO_ADV.RBU_MIGRATION;
end;
/

The function returns the sizing information directly.

Best Practices

This following list of recommendat ions will help you manage your undo space to best advantage.

  • You need not set a value for the UNDO _RETENTION parameter unless your system has flashback or LOB retention requirements.

  • Allow 10 to 20% extra space in your undo tablespace to provide for some fluctuation in your workload.

  • Set the warnin g and critical alert thresholds for the undo tablespace alert properly. Please refer to "Managing Space in Tablespaces " for information on how to set alert thresholds for the undo tablespace.

  • To tune SQ L queries or to check on runaway queries, use the value of the SQLID column provided in the long query or in the V $UNDOSTAT or WRH$_UNDOSTAT views to retrieve SQL text and other details on the SQL from V$SQL view.< /p>

  • Always use indexes for Flashback Version Query.