OORRAACCLLEE99II SSPPAACCEE MMAANNAAGGEEMMEENNTT DDEEMMYYSSTTIIFFIIEEDD
Sushil Kumar, Oracle Corporation [email protected]
INTRODUCTION Database space management has always been an important part of any database administrator's job. Administrators spend a significant amount of their time planning and monitoring space utilization to ensure uninterrupted database operations. Oracle9i takes a giant leap forward in making the life of a database administrator easier by introducing several new features that simplify routine administration, enforce best practices, and eliminate much space-related performance tuning. This presentation explores three of those features: Automatic Undo Management, Locally Managed Tablespaces, and Automatic Segment Space Management. It provides a detailed explanation of how they work, what problems they solve, and how.
AUTOMATIC UNDO MANAGEMENT
ROLLBACK SEGMENTS REVIEWED One of the most unique aspects of the Oracle database is its version based read consistency model. As opposed to storing the undo data (i.e. the data required to rollback a change) in recovery log files as done by other Relational Database Management System (RDBMS) products, Oracle stores this data right in the database itself. This allows the Oracle database to service queries without requiring any read locks as well as to wrap around the log file without waiting for transactions to commit. Consequently, Oracle DBAs need not even think about some of the most time consuming tasks that their DB2 and SQL Server counterparts have to perform on a daily basis i.e. resolving deadlocks and monitoring uncommitted transactions. Prior to Oracle9i, database structures called “rollback segments” are used to store undo transaction information. Besides rolling back an uncommitted transaction, the undo data is also used for read consistency and recovery purposes. Although rollback segments are structurally similar to any other data or index segment, their management greatly differs from those of regular segments.
Each rollback segment consists of a transaction table with two or more extents of undo blocks. A transaction writes to only one extent at a time, although several transactions can share the same extent. Rollback segment extents are used in a circular fashion with transactions moving from one extent to the next after the current extent is filled. To manage transactions, a “head and tail” mechanism is employed such that the head is the pointer location of the current uncommitted transaction record and the tail is the pointer location to the oldest uncommitted transaction record. The rollback segment mechanism always tries to reuse the next extent in the “ring” unless there is an active transaction occupying that extent. It may be noted here that Oracle never re-uses a rollback segment extent as long as it contains active transactions. If an active transaction is found in the next extent, a new extent will be allocated and brought into the ring. The failure to allocate additional extents results in an ORA-1562 error (Failure to extend rollback segment……). As each transaction commits, its transaction space (or undo information) will be available for other transactions.
The rollback segments are created by administrators either at the time of database creation or later. An administrator can create as many rollback segments as required. However, picking up the right number of rollback segments and determining their sizes can be a challenging task. Few large rollback segments can cause contention for transaction tables thereby adversely impacting the performance while many small rollback segments can lead to transaction failure since a transaction can use only one rollback segment.
Paper # 32707
INTRODUCING AUTOMATIC UNDO MANAGEMENT
Oracle9i provides a new mechanism for managing the undo space within a database. In this mode, administrators merely need to indicate the amount of disk space available for storing undo data by creating an “Undo Tablespace”. The database server, then, automatically allocates and manages the space within the undo tablespace among various active sessions. Automatic Undo Management feature also provides a way for administrators to exert control on the undo retention. A DBA can specify the duration for which the undo data should be retained in terms of wall-clock time (number of seconds). For example, to configure a database to support queries that run for 30 minutes or less, the DBA can simply set the undo retention parameter to 30 minutes. With retention control, users can configure their systems to allow long running queries to execute successfully without encountering ORA-1555 (Snapshot too old) errors. The undo retention time is persistent and is remembered across system shutdowns. It can be specified using a new INIT.ORA parameter, UNDO_RETENTION. This parameter is dynamic and hence can be changed anytime during database operation using the ALTER SYSTEM command.
In order to prevent a rogue transaction from consuming excessive undo space and thus impacting system operation, Oracle9i allows assigning an undo quota at the resource consumer group level using a newly introduced resource manager plan directive UNDO_POOL. Whenever the total undo consumed by a group exceeds its limit, its sessions will not be allowed to execute any more DML statements until some undo space is freed by other sessions of this group after their transactions commit or abort.
Rollback Segments are supported in Oracle9i to ensure backward compatibility. The UNDO_MANAGEMENT parameter allows administrators to switch between automatic and manual (rollback segment) mode.
HOW DOES AUTOMATIC UNDO MANAGEMENT WORK?
THE UNDO TABLESPACE As stated earlier, the Automatic Undo Management feature uses Undo Tablespaces to store the undo information. Undo tablespaces are a special type of locally managed tablespaces (with system managed extent sizes) used solely for storing undo information. Creation of other database objects such as tables, indexes is not allowed in this tablespace. An undo tablespace can be created either at the time of database creation (using the UNDO TABLESPACE clause in the CREATE DATABASE command) or later. Also, a database can have more than one undo tablespace but only one of them will be used by a database instance at a time. In Real Application Clusters (RAC) environment, each instance has its own undo tablespace for storing its undo data. However, each instance can read data from the undo tablespaces owned by other instances for "consistent read" purposes. Also, any instance can update an undo tablespace during transaction recovery as long as it is not already being used by any other instance either for undo generation by an active transaction or transaction recovery. It is possible to switch the undo tablespace being used by an instance in case the administrator decides to create a different undo tablespace. The process of switching the undo tablespace is an online operation and happens totally behind the scene without stopping the database or impacting users.
UNDO SEGMENTS An undo tablespace consists of a number of “undo segments”. The undo segments are structurally similar to rollback segment. Each undo segment is composed of a transaction table and a set of undo blocks, managed in units of extents. However, unlike rollback segments, the database server automatically manages the number and sizes of the undo segments. A small number of undo segments is automatically created at the time of undo tablespace creation. Later when the undo tablespace is “activated”, either automatically by the database server if it is the only undo tablespace in the database or manually by the administrator using the ALTER SYSTEM SET UNDO_TABLESPACE command, a subset of these undo segments is made online. To the extent possible, Automatic Undo Management attempts to assign one transaction per undo segment (transaction table). If the number of active transactions exceeds the number of available online undo segments in the undo tablespace, rest of the undo segments will be made online. The database server will automatically create new undo segments if none are available. During quiet periods, some of these undo segment, which are no longer being used, may either be made offline or dropped. Under the normal
Paper # 32707
circumstances, automatic creation of undo segments should only occur at ramp-up time i.e. the first time when the undo tablespace does not yet have enough transaction tables. In the event that undo segments cannot be created (e.g. when the undo tablespace is out of space), the new transaction will share an undo segment with other transactions. For load balancing, the undo segment with the least number of active transactions will be chosen. UNDO RETENTION As said earlier, Automatic Undo Management allows administrators to specify how long the undo data should be preserved using the UNDO_RETENTION initialization parameter. To provide this functionality, each undo extent “remembers” the time when the last transaction, using this undo segment, was committed. Based on this time, an undo extent can either be in “expired” or “unexpired” state – “expired” if the difference between current and the last commit time is more than the UNDO_RETENTION period and “unexpired” otherwise. Oracle makes every possible effort not to overwrite the contents of an unexpired extent in order to honor undo retention setting.
SPACE MANAGEMENT Unlike rollback segments, undo segments are highly dynamic in size. Oracle autom