Managing the Undo Tablespace

导读：

　　This chapter describes how to manage the undo tablespace, which 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 database. Such information consists of records of the actions of transactions, primarily before they are committed. These records are collectively referred to as undo.

　　Undo records are used to:

　　Roll back transactions when a ROLLBACKstatement is issued

　　Recover the database

　　Provide read consistency

　　Analyze data as of an earlier point in time by using Oracle Flashback Query

　　Recover from logical corruptions using Oracle Flashback features

　　When a ROLLBACKstatement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency 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.

　　 Introduction to Automatic Undo Management

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

　　 Overview of Automatic Undo Management

　　Oracle provides a fully automated mechanism, referred to as automatic undo management, for managing undo information and space. In this management mode, you create an undo tablespace, and the server automatically manages undo segments and space among the various active sessions.

　　You set the UNDO_MANAGEMENTinitialization parameter to AUTOto enable automatic undo management.A default undo tablespace is then created at database creation. An undo tablespace can also be created explicitly. The methods of creating an undo tablespace are explained in "Creating an Undo Tablespace".

　　When the instance starts, the database automatically selects the first available undo tablespace. If no undo tablespace is available, then the instance starts without an undo tablespace and stores undo records in the SYSTEMtablespace. This is not recommended in normal circumstances, and an alert message is written to the alert log file to warn that the system is running without an undo tablespace.

　　If the database contains multiple undo tablespaces, you can optionally specify at startup that you want to use a specific undo tablespace. This is done by setting the UNDO_TABLESPACEinitialization parameter, as shown in this example:

　　UNDO_TABLESPACE = undotbs_01



　　In this case, if you have not already created the undo tablespace (in this example, undotbs_01), the STARTUPcommand fails. The UNDO_TABLESPACEparameter can be used to assign a specific undo tablespace to an instance in an Oracle Real Application Clusters environment.

　　The following is a summary of the initialization parameters for automatic undo management:

　　

Initialization Parameter	Description
UNDO_MANAGEMENT	If AUTO, use automatic undo management. The default is MANUAL.
UNDO_TABLESPACE	An optional dynamic parameter specifying the name of an undo tablespace. 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 tablespace.

　　When automatic undo management is enabled, if the initialization parameter file contains parameters relating to manual undo management, they are ignored.

　　 See Also:

　　Oracle Database Referencefor complete descriptions of initialization parameters used in automatic undo management

　　 Undo Re tention

　　After a transaction is committed, undo data is no longer needed for rollback or transaction recovery purposes. However, for consistent read purposes, long-running queries may require this old undo information for producing older images of data blocks. Furthermore, the success of several Oracle Flashback features can also depend upon the availability of older undo information. For these reasons, it is desirable to retain the old undo information for as long as possible.

　　When automatic undo management is enabled, there is always a current undo retention period, which is the minimum amount of time that Oracle Database attempts to retain old undo information before overwriting it. Old (committed) undo information that is older than the current undo retention period is said to be expired. Old undo information with an age that is less than the current undo retention period is said to be unexpired.

　　Oracle Database automatically tunes the undo retention period based on undo tablespace size and system activity. You can specify a minimum undo retention period (in seconds) by setting the UNDO_RETENTIONinitialization parameter. The database makes its best effort to honor the specified minimum undo retention period, provided that the undo tablespace has space available for new transactions. When available space for new transactions becomes short, the database begins to overwrite expired undo. If the undo tablespace has no space for new transactions after all expired undo is overwritten, the database may begin overwriting unexpired undo information. If any of this overwritten undo information is required for consistent read in a current long-running query, the query could fail with the snapshottooolderror message.

　　The following points explain the exact impact of the UNDO_RETENTIONparameter on undo retention:

　　The UNDO_RETENTIONparameter is ignored for a fixed size undo tablespace. The database may overwrite unexpired undo information when tablespace space becomes low.

　　For an undo tablespace with the AUTOEXTENDoption enabled, the database attempts to honor the minimum retention period specified by UNDO_RETENTION. When space is low, instead of overwriting unexpired undo information, the tablespace auto-extends. If the MAXSIZEclause is specified for an auto-extending undo tablespace, when the maximum size is reached, the database may begin to overwrite unexpired undo information.

　　 Reten tion Guarantee

　　To guarantee the success of long-running queries or Oracle Flashback operations, you can enable retention guarantee. If retention guarantee is enabled, the specified minimum undo retention is guaranteed; the database never overwrites unexpired undo data even if it means that transactions fail due to lack of space in the undo tablespace. If retention guarantee is not enabled, the database can overwrite unexpired undo when space is low, thus lowering the undo retention for the system. This option is disabled by default.

　　 WARNING:

　　Enabling retention guarantee can cause multiple DML operations to fail. Use with caution.

　　You enable retention guarantee by specifying the RETENTION GUARANTEEclause for the undo tablespace when you create it with either the CREATE DATABASEor CREATE UNDO TABLESPACEstatement. Or, you can later specify this clause in an ALTER TABLESPACEstatement. You disable retention guarantee with the RETENTION NOGUARANTEEclause.

　　You can use the DBA_TABLESPACESview to determine the retention guarantee setting for the undo tablespace. A column named RETENTIONcontains a value of GUARANTEE, NOGUARANTEE, or NOT APPLY(used for tablespaces other than the undo tablespace).

　　 Automatic Tun ing of Undo Retention

　　Oracle Database automatically tunes the undo retention period based on how the undo tablespace is configured.

　　If the undo tablespace is fixed size, the database tunes the retention period for the best possible undo retention for that tablespace size and the current system load. This tuned retention period can be significantly greater than the specified minimum retention period.

　　If the undo tablespace is configured with the AUTOEXTENDoption, the database tunes the undo retention period to be somewhat longer than the longest-running query on the system at that time. Again, this tuned retention period can be greater than the specified minimum retention period.

　　 Note:

　　Automatic tuning of undo retention is not supported for LOBs. This is because undo information for LOBs is stored in the segment itself and not in the undo tablespace. For LOBs, the database attempts to honor the minimum undo retention period specified by UNDO_RETENTION. However, if space becomes low, unexpired LOB undo information may be overwritten.

　　You can determine the current retention period by querying the TUNED_UNDORETENTIONcolumn of the V$UNDOSTATview. This view contains one row for each 10-minute statistics collection interval over the last 4 days. (Beyond 4 days, the data is available in the DBA_HIST_UNDOSTATview.) TUNED_UNDORETENTIONis given in seconds.

　　select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,

to_char(end_time, 'DD-MON-RR HH24:MI') end_time, tuned_undoretention

from v$undostat order by end_time;

BEGIN_TIME END_TIME TUNED_UNDORETENTION

--------------- --------------- -------------------

04-FEB-05 00:01 04-FEB-05 00:11 12100

...

07-FEB-05 23:21 07-FEB-05 23:31 86700

07-FEB-05 23:31 07-FEB-05 23:41 86700

07-FEB-05 23:41 07-FEB-05 23:51 86700

07-FEB-05 23:51 07-FEB-05 23:52 86700

576 rows selected.



　　See Oracle Database Referencefor more information about V$UNDOSTAT.

　　 Undo Retention Tuning and Alert Thresholds For a fixed size undo tablespace, the database calculates the maximum undo retention period based on database statistics and on the size of the undo tablespace. For optimal undo management, rather than tuning based on 100% of the tablespace size, the database tunes the undo retention period based on 85% of the tablespace size, or on the warning alert threshold percentage for space used, whichever is lower. (The warning alert threshold defaults to 85%, but can be changed.) Therefore, if you set the warning alert threshold of the undo tablespace below 85%, this may reduce the tuned length of the undo retention period. For more information on tablespace alert thresholds, see "Managing Tablespace Alerts".

　　 Setting the Undo Rete ntion Period

　　You set the undo retention period by setting the UNDO_RETENTIONinitialization parameter. This parameter specifies the desired minimumundo retention period in seconds. As described in "Undo Retention", the current undo retention period may be automatically tuned to be greater than UNDO_RETENTION, or, unless retention guarantee is enabled, less than UNDO_RETENTIONif space is low.

　　 To set the undo retention period:

　　Do one of the following:

　　Set UNDO_RETENTIONin the initialization parameter file.

　　UNDO_RETENTION = 1800



　　Change UNDO_RETENTIONat any time using the ALTER SYSTEMstatement:

　　ALTER SYSTEM SET UNDO_RETENTION = 2400;



　　The effect of an UNDO_RETENTIONparameter change is immediate, but it can only be honored if the current undo tablespace has enough space.

　　 Sizing the Undo Tablespace

　　You can size the undo tablespace appropriately either by using automatic extension of the undo tablespace or by using the Undo Advisor for a fixed sized tablespace.

　　 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 this case, you can enable automatic extension of the undo tablespace so that it automatically increases in size when more space is needed. You do so by including the AUTOEXTENDkeyword when you create the undo tablespace.

　　 Sizing Fixed-Size Undo Tablespaces

　　If you have decided on a fixed-size undo tablespace, the Undo Advisor can help you estimate needed capacity. You can access the Undo Advisor through Enterprise Manager or through the DBMS_ADVISORPL/SQL package. Enterprise Manager is the preferred method of accessing the advisor. For more information on using the Undo Advisor through Enterprise Manager, please refer to Oracle Database 2 Day DBA.

　　The Undo Advisor relies for its analysis on data collected in the Automatic Workload Repository (AWR). It is therefore important that the AWR have adequate workload statistics available so that the Undo Advisor can make accurate recommendations. For newly created databases, adequate statistics may not be available immediately. In such cases, an auto-extensible undo tablespace can be used.

　　An adjustment to the collection interval and retention period for AWR statistics can affect the precision and the type of recommendations that the advisor produces. See "Automatic Workload Repository"for more information.

　　To use the Undo Advisor, you first estimate these two values:

　　The length of your expected longest running query

　　After the database has been up for a while, you can view the Longest Running Query field on the Undo Management page of Enterprise Manager.

　　The longest interval that you will require for flashback operations

　　For example, if you expect to run Flashback Queries for up to 48 hours in the past, your flashback requirement is 48 hours.

　　You then take the maximum of these two undo retention values and use that value to look up the required undo tablespace size on the Undo Advisor graph.

　　 The Undo Advisor PL/SQL Interface

　　You can activate the Undo Advisor by creating an undo advisor task through the advisor framework. The following example creates an undo advisor task to evaluate the undo tablespace. The name of the advisor is 'Undo Advisor'. The analysis is based on Automatic Workload Repository snapshots, which you must specify by setting parameters START_SNAPSHOTand END_SNAPSHOT. In the following example, the START_SNAPSHOTis "1" and END_SNAPSHOTis "2".

　　DECLARE

tid NUMBER;

tname VARCHAR2(30);

oid NUMBER;

BEGIN

DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');

DBMS_ADVISOR.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);

DBMS_ADVISOR.SET_TASK_PARAMETER(name, 'INSTANCE', 1);

DBMS_ADVISOR.execute_task(tname);

end;

/



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

　　 See Also:

　　Oracle Database 2 Day DBAfor more information on using advisors and "Using the Segment Advisor"for an example of creating an advisor task for a different advisor

　　Oracle Database Referencefor information about the DBA_ADVISOR_*data dictionary views

　　 Managing 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 when the CREATE DATABASEstatement is issued. This occurs when you are creating a new database, and the instance is started in automatic undo management mode (UNDO_MANAGEMENT = AUTO). The second method is used with an existing database. It uses the CREATE UNDO TABLESPACEstatement.

　　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, tablespaces are discussed in "Bigfile Tablespaces".

　　 Using CREATE DATABASE to Create an Undo Tablespace

　　You can create a specific undo tablespace using the UNDO TABLESPACEclause of the CREATE DATABASEstatement.

　　The following statement illustrates using the UNDO TABLESPACEclause in a CREATE DATABASEstatement. The undo tablespace is named undotbs_01and one datafile, /u01/oracle/rbdb1/undo0101.dbf, is allocated for it.

　　CREATE DATABASE rbdb1

CONTROLFILE REUSE

.

.

.

UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';



　　If the undo tablespace cannot be created successfully during CREATE DATABASE, the entire CREATE DATABASEoperation fails. You must clean up the database files, correct the error and retry the CREATE DATABASEoperation.

　　The CREATE DATABASEstatement 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 Referencefor the syntax for using the CREATE DATABASEstatement to create an undo tablespace

　　 Using the CREATE UNDO TABLESPACE Statement

　　The CREATE UNDO TABLESPACEstatement is the same as the CREATE TABLESPACEstatement, but the UNDOkeyword is specified. The database determines most of the attributes of the undo tablespace, but you can specify the DATAFILEclause.

　　This example creates the undotbs_02undo tablespace with the AUTOEXTENDoption:

　　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 of them can be active at any one time.

　　 See Also:

　　Oracle Database SQL Referencefor the syntax for using the CREATE UNDO TABLESPACEstatement to create an undo tablespace

　　 Altering an Undo Tablespace

　　Undo tablespaces are altered using the ALTER TABLESPACEstatement. 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

　　Beginning 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 prevent it from doing so, you can add more files to it or resize existing datafiles.

　　The following example adds another datafile to 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...DATAFILEstatement to resize or extend a datafile.

　　 See Also:

　　Oracle Database SQL Referencefor ALTER TABLESPACEsyntax

　　 Dropping an Undo Tablespace

　　Use the DROP TABLESPACEstatement to drop an undo tablespace. The following example drops the undo tablespace 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 transaction died but has not yet been recovered), the DROP TABLESPACEstatement fails. However, since DROP TABLESPACEdrops an undo tablespace even if it contains unexpired undo information (within retention period), you must be careful not to drop an undo tablespace if undo information is needed by some existing queries.

　　DROP TABLESPACEfor undo tablespaces behaves like DROP TABLESPACE...INCLUDING CONTENTS. All contents of the undo tablespace are removed.

　　 See Also:

　　Oracle Database SQL Referencefor DROP TABLESPACEsyntax

　　 Switching Undo Tablespaces

　　You can switch from using one undo tablespace to another. Because the UNDO_TABLESPACEinitialization parameter is a dynamic parameter, the ALTER SYSTEM SETstatement can be used to assign a new undo tablespace.

　　The following statement switches to a new undo tablespace:

　　ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;



　　Assuming undotbs_01is the current undo tablespace, after this command successfully executes, the instance uses undotbs_02in place of undotbs_01as its undo tablespace.

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

　　The tablespace does not exist

　　The tablespace is not an undo tablespace

　　The tablespace is already being used by another instance (in a RAC environment only)

　　The database is online while the switch operation is performed, and user transactions can be executed while this command is being executed. When the switch operation completes successfully, all transactions started after the switch operation 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 enters into a PENDING OFFLINEmode (status). In this mode, existing transactions can continue to execute, but undo records for new user transactions cannot be stored in this undo tablespace.

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

　　If the parameter value for UNDO TABLESPACEis set to ' (two single quotes), then the current undo tablespace is switched out and the next available undo tablespace is switched in. Use this statement with care because there may be no undo tablespace available.

　　The following example unassigns the current undo tablespace:

　　ALTER SYSTEM SET UNDO_TABLESPACE = ';



　　 Establishing User Quotas for Undo Space

　　The Oracle Database Resource Manager can be used to establish user quotas for undo space. The Database Resource Manager directive UNDO_POOLallows DBAs to limit the amount of undo space consumed by a group of users (resource consumer group).

　　You can specify an undo pool for each consumer 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 UPDATEtransaction generating the undo is terminated. No other members of the consumer group can perform further updates until undo space is freed from the pool.

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

　　 Migrating to Automatic Undo Management

　　If you are currently using rollback segments to manage undo space, Oracle strongly recommends that you migrate your database to automatic undo management. Oracle Database provides a function that provides information on how to size your new undo tablespace based on the configuration and usage of the rollback segments in your system. DBA privileges are required to execute this function:

　　DECLARE

utbsiz_in_MB NUMBER;

BEGIN

utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;

end;

/



　　The function returns the sizing information directly.

　　 Viewing Information About Undo

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

　　Oracle Database also provides proactive help in managing tablespace disk space use by alerting you when tablespaces run low on available space. Please refer to "Managing Tablespace Alerts"for information on how to set alert thresholds for the undo tablespace.

　　In addition to the proactive undo space alerts, Oracle Database also provides alerts if your system has long-running queries that cause SNAPSHOT TOO OLDerrors. To prevent excessive alerts, the long query alert is issued at most once every 24 hours. When the alert is generated, you can check the Undo Advisor Page 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 space. Use this view to help estimate the amount of undo space required for the current workload. The database also uses this information 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
DBA_UNDO_EXTENTS	Shows the status and size of each extent in the undo tablespace.
DBA_HIST_UNDOSTAT	Contains statistical snapshots of V$UNDOSTAT information. Please refer to Oracle Database 2 Day DBA for more information.

　　 See Also:

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

　　The V$UNDOSTATview is useful for monitoring the effects of transaction execution on undo space in the current instance. Statistics are available for undo space consumption, transaction concurrency, the tuning of undo retention, and the length and SQL ID of long-running queries in the instance.

　　Each row in the view contains statistics collected in the instance for a ten-minute interval. The rows are in descending order by the BEGIN_TIMEcolumn value. Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME). Each column represents the data collected for the particular statistic in that time interval. The first row of the view contains statistics for the (partial) current time period. The view contains a total of 576 rows, spanning a 4 day cycle.

　　The following example shows the results of a query on the V$UNDOSTATview.

　　SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,

TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,

UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON"

FROM v$UNDOSTAT WHERE rownum <= 144;



BEGIN_TIME END_TIME UNDOTSN UNDOBLKS TXNCOUNT MAXCON

------------------- ------------------- ---------- ---------- ---------- ----------

10/28/2004 14:25:12 10/28/2004 14:32:17 8 74 12071108 3

10/28/2004 14:15:12 10/28/2004 14:25:12 8 49 12070698 2

10/28/2004 14:05:12 10/28/2004 14:15:12 8 125 12070220 1

10/28/2004 13:55:12 10/28/2004 14:05:12 8 99 12066511 3

...

10/27/2004 14:45:12 10/27/2004 14:55:12 8 15 11831676 1

10/27/2004 14:35:12 10/27/2004 14:45:12 8 154 11831165 2



144 rows selected.



本文转自

http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm