Oracle9i Database

OORRAACCLLEE99II SSPPAACCEE MMAANNAAGGEEMMEENNTT DDEEMMYYSSTTIIFFIIEEDD

Sushil Kumar, Oracle Corporation Sushil.Kumar@oracle.com

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

Oracle9i Database

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

Oracle9i Database

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 automatically extends and shrinks undo segments as needed thereby making most effective use of available disk space. Consequently, unlike manual rollback space management, where amount of undo space that a transaction can use is limited by size of its rollback segment, there is no such limit while using Automatic Undo Management. However, as stated before, administrators can define their own limit using the UNDO_POOL resource manager directive to prevent a runaway transaction from monopolizing the whole undo tablespace.

Also, while the database makes the best possible effort not to overwrite the contents of an unexpired extent, it is forced to use them if no space is available in the undo tablespace in order to avoid transaction failures. Therefore, the undo tablespace must be sized large enough in order to “guarantee” undo retention.

BENEFITS

ENHANCED MANAGEABILITY The most significant benefit of the Automatic Undo Management feature is the ease of use. With Automatic Undo Management, administrators merely need to create an UNDO tablespace with sufficient disk space instead of manually creating a number of rollback segments and strategically assigning transactions to rollback segments large enough to accommodate generated rollback data. By automatically adjusting the number of undo segments so that each transaction gets its own transaction table, this feature also frees DBAs from adjusting the attributes of rollback segments to avoid undo block and consistent read contention.

DETERMINISTIC UNDO RETENTION The ability to specify undo retention helps administrators prevent ORA-1555 (Snapshot too old) error message, as explained earlier. It also makes it possible for users to query a past snapshot of data using the flashback query feature. This is an extremely powerful functionality which can be used to recover from user errors, such accidental deletion of data, online with little or no intervention from database administrator. For more information on flashback query, please refer to Oracle white paper “Oracle9i Flashback Query” at http://otn.oracle.com/deploy/availability/pdf/FlashbackQueryBWP.pdf.

IMPROVED SPACE UTILIZATION The Automatic Undo Management feature allows dynamic redistribution of undo space between undo segments. As a result, undo space no longer needs be statically divided into a number of rollback segments, where transactions can encounter “Out of Undo Space” error even when plenty of undo space is available in the database if the rollback segment of the transaction runs out of space.

USING AUTOMATIC UNDO MANAGEMENT

ENABLING AUTOMATIC UNDO MANAGEMENT The Automatic Undo Management feature can be enabled by setting the initialization parameter

Paper # 32707

http://otn.oracle.com/deploy/availability/pdf/FlashbackQueryBWP.pdf

Oracle9i Database

UNDO_MANAGEMENT to AUTO. In addition, an undo tablespace also needs to be created as discussed earlier. The compatible parameter must be set to 9.0.0 in order to use this feature. Following are the step-by-step directions to enable Automatic Undo management for new and existing databases.

NEW DATABASE The Automatic Undo Management feature is automatically enabled for databases created using the Database Configuration Assistant (DBCA). For databases created using scripts,

1. Set the following initialization parameter a. UNDO_MANAGEMENT=AUTO and b. COMPATIBLE = 9.0.0

2. Specify the UNDO TABLESPACE clause in the CREATE DATABASE command CREATE DATABASE mynewdb LOGFILE GROUP 1 ('/vobs/oracle/oradata/mynewdb/redo01.log') SIZE 100M, GROUP 2 ('/vobs/oracle/oradata/mynewdb/redo02.log') SIZE 100M, ………………………………

GROUP 3 ('/vobs/oracle/oradata/mynewdb/redo03.log') SIZE 100M

……………………………… UNDO TABLESPACE undotbs DATAFILE '/vobs/oracle/oradata/mynewdb/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED;

EXISTING DATABASE 1. If using SPFILE, execute the following command

ALTER SYSTEM SET COMPATIBLE=9.0.0

2. Shutdown the database

3. If using PFILE (init.ora file), edit it to set COMPATIBLE=9.0.0

4. Start the Instance back up. With compatible parameter set to 9.0.0, an undo tablespace can now be created.

5. Create the undo TABLESPACE using the CREATE UNDO TABLESPACE command CREATE UNDO TABLESPACE undotbs_1 DATAFILE ‘undotbs_1a.f’ size 2M reuse autoextend on;

6. If using SPFILE, execute the following command ALTER SYSTEM SET UNDO_MANAGEMENT=AUTO SCOPE=SPFILE;

7. Shutdown the Instance cleanly (using SHUTDOWN IMMEDIATE or SHUTDOWN NORMAL commands)

8. If using PFILE, add the UNDO_MANAGEMENT=AUTO entry

9. Start the instance again. The Automatic Undo Management is now enabled!

The parameter UNDO_TABLESPACE can be used to direct an instance to use a particular undo tablespace, if more than one exists in the database. It can be used in RAC environment to statically bind undo tablespace with individual instances. Its use, however, is completely optional since instance can automatically pick one of the available undo tablespaces for its use if none is specified. Therefore, if there is only one undo tablespace in the database, there is no need to set this parameter.

In Automatic Undo Management mode, any DDL statement referencing rollback segment such as SET TRANSACTION USE ROLLBACK SEGMENT will generate errors (rest of the operation will continue however).

Paper # 32707

Oracle9i Database

The UNDO_SUPPRESS_ERRORS parameter can be set to TRUE to suppress these messages.

SETTING UNDO_RETENTION The primary motivation behind the UNDO_RETENTION parameter is to prevent occurrence of ORA-1555 (Snapshot too old) error messages. Therefore, its value should at least be equal to the length of longest running query on a given database instance.

For a new database, where the exact nature of workload may be unknown making it difficult to predict the duration of the longest query, the following values could be a good starting point.

Workload Type UNDO_RETENTION Value

OLTP Default (900 i.e. 15 Minutes)

MIXED 3600 (1 Hour)

DSS (Data warehouse) 10800 (3 Hours)

Once the database has been in existence for a while, a more precise value can be found by querying the V$UNDOSTAT view, as shown below.

SQL> select max(maxquerylen) from v$undostat; MAX(MAXQUERYLEN) ---------------- 202

SIZING THE UNDO TABLESPACE As per above discussion, the undo tablespace should be large enough to store the undo data generated by active transaction as well as those “preserved” to honor the undo retention setting. Oracle Enterprise Manager Undo Tablespace advisory can help adjust the size of the undo tablespace on an ongoing basis. This undo tablespace advisor predicts the size of undo tablespace to support a given value of undo retention based on data available in the V$UNDOSTAT view.

Paper # 32707

Oracle9i Database

Figure 1: Enterprise Manager Undo Tablespace Sizing Advisory

MONITORING AND TUNING

The V$UNDOSTAT dynamic performance view presents a wide range of statistics related to functioning of automatic undo management. It displays a histogram of statistical data to show how well the system is working. The available statistics include undo space consumption, transaction concurrency, and length of queries executed in the instance. This view can be used to estimate the amount of undo space required for the current workload. This view is available in both automatic undo management mode and manual undo management mode.

Each row in the view keeps statistics collected in the instance for a 10-minute interval. Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME) and 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 1008 rows, spanning a 7-day cycle.

The following tables describes the some of statistics contained in the view and how can they be used to adjust the size of the undo tablespace as well as the value of the UNDO_RETENTION parameter

Column Description

UNDOBLKS Represents the total number of undo blocks consumed. This statistics can be used to obtain the consumption rate of undo blocks, and thereby estimate the size of the undo tablespace needed to handle the workload on your system.

MAXQUERYLEN Identifies the length of the longest query (in seconds) executed in the instance during the period. It can be used to estimate the proper setting of the UNDO_RETENTION initialization parameter, as stated above.

Paper # 32707

Oracle9i Database

Column Description

UNXPSTEALCNT Number of times a transaction attempted to obtain undo space by stealing unexpired extents from other undo segments. A non-zero value means that the current size of undo tablespace may not be big enough to support the UNDO_RETENTION setting. The remedy is to either increase the size of undo tablespace or decrease the undo retention period.

UNXPBLKREUCNT Number of times that a transaction reused the unexpired undo blocks belonging to its current undo segment. A non-zero value means that the current size of undo tablespace is not big enough to support the UNDO_RETENTIION setting. The remedy is to either increase the size of undo tablespace or decrease the undo retention period.

SSOLDERRCNT Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error.

NOSPACEERRCNT Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.

The following additional views are also available.

View Name Description

DBA_UNDO_EXTENTS Provides details about undo extents e.g. extent name, size and status (expired, unexpired, active)

V$ROLLSTAT This view is available both for manual and automatic undo management. In the automatic mode, it provides the details about undo segments extends, wraps, shrinks, and other related statistics.

V$TRANSACTION Provides information about the undo segment in use by transactions

TROUBLESHOOTING

UNDO TABLESPACE CORRUPTION Like Rollback segments, the Automatic Undo Management feature continues to support recovery from undo corruptions. Oracle support should be contacted under such circumstances to recover the database in a graceful manner.

UNDO TABLESPACE RECOVERY The process of recovering an undo tablespace is very similar to that of rollback segment. A media recovery can be performed if the database is running in the ARCHIVELOG mode. Otherwise, the “lost” undo tablespace needs to be discarded and a new undo tablespace should be created. However, since discarding the undo tablespace may cause violation of undo retention period, running database in ARCHIVELOG mode is highly recommended.

Paper # 32707

Oracle9i Database

Following are the step-by-step instructions to recover the undo tablespace recovery using methods explained above.

MEDIA RECOVERY 1. Restore the backup copy of the lost undo datafile and mount the database.

2. If no prior backup exists, the file(s) can still be recovered if all archive log files since the undo tablespace was created are still available. Create empty file(s) with the same name as that of the lost files as shown below. SQL> alter database create datafile 'ut1.f'; Database altered.

3. Perform media recovery

SQL> recover datafile 'ut1.f';

Media recovery complete.

4. Open the database SQL> alter database open; Database altered.

The undo tablespace should now be completely recovered.

DISCARDING LOST UNDO TABLESPACE 1. Mount the instance and drop the lost file(s) SQL> alter database datafile 'ut1.f' offline drop; Database altered.

2. The database can now be opened. However, the lost undo tablespace and its undo segments will still show up in the data dictionary.

SQL> alter database open; Database altered. SQL> select segment_name, status from dba_rollback_segs; SEGMENT_NAME STATUS ------------------------------ ---------------- SYSTEM ONLINE T_RS1 OFFLINE _SYSSMU2$ OFFLINE _SYSSMU3$ OFFLINE _SYSSMU4$ OFFLINE

3. Create a new undo tablespace and drop the old one. SQL> create undo tablespace ut2 datafile 'ut2.f' size 500k; Tablespace created. SQL> alter system set undo_tablespace=ut2; System altered. SQL> drop tablespace ut1 including contents; Tablespace dropped.

4. That completes the “recovery” process -- not a recovery in true sense since we are not getting back the lost file. Everything should be fine now.

Paper # 32707

Oracle9i Database

SQL> select segment_name, status from dba_rollback_segs; SEGMENT_NAME STATUS ------------------------------ ---------------- SYSTEM ONLINE T_RS1 OFFLINE _SYSSMU5$ ONLINE _SYSSMU6$ ONLINE _SYSSMU7$ ONLINE

CUSTOMER IMPLEMENTATION SUCCESS STORIES

Automatic Undo Management is, undoubtedly, one of the most significant benefits of Oracle9i. Not only it makes life much simpler for database administrators, it also enables a very unique and powerful data recovery mechanism. A large number of customers all across the globe have already successfully implemented this feature and their number continues to swell every day. The following table lists some of these customers:

Customer Name Business Description System/Environment Details Talkline Mobile phone & services company

in Germany (http://www.talkline.de)

• Sun E-10000 (20 CPUs, 8GB RAM)

• 4 x A5200 (72 x 18 GB disks), 1 x A3500 (18 x 9 GB disks), 340 MB/sec. throughput

• DWH: 1/2 TB raw data, largest table 100 GB

Nordac A leading IT partner and service provider for medium-sized companies in Germany (http://www.nordac.de)

50 GB 2-node RAC database supporting a Logistics application running on 1 GHz single CPU ES45 Alpha Server (True64) with 4GB RAM

Bauer Verlagsgruppe A major German publishing group (http://www.hbv.de)

3 GB 2-node (Two IBM Netfinity 5800R systems with 4 CPUS and 4GB RAM each)RAC OLTP database serving up to 250 users

Postbank A Germany based international banking group (http://www.postbank.de)

Oracle9i Release 2 RAC running on HP-UX

KITC, South Korea A South Korean security brokerage and corporate finance service firm (http://www.hantutams.com)

A 500 GB 2-node (HP SuperDome 32000 ,12 CPU, 16G) RAC database running on HP-UX 11.11 servicing a stock trading applications with up to 1 million transactions per day.

P&O Ports World leader in cargo handling and port management (http://poports.com)

Database supporting company’s portal http://poports.com

LOCALLY MANAGED TABLESPACES

OVERVIEW

The space within a tablespace has traditionally been managed using the data dictionary. A set of data dictionary tables keep track of the extents belonging to different tablespaces and they need to be updated each time any kind of space management operation, such as adding or removing an extent, is performed.

Paper # 32707

Oracle9i Database

Oracle8i introduced a new type of tablespace that uses bitmaps, stored in the datafile headers, to manage its free and used space. Since the bitmaps are stored “locally” within the tablespace (i.e. not in the dictionary tables), these tablespaces are known as “Locally Managed Tablespaces”. Each bit in a bitmap represents a set of blocks and the status of bitmap is changed each time an extent is either allocated or freed. Since no dictionary updates are required to reflect change in space usage, space management operations in a locally managed tablespace do not generate any undo information either1. Also, unlike dictionary managed tablespaces, locally managed tablespaces automatically coalesce free space. Locally Managed Tablespaces provide two options available to determine the extent sizes. The first option allows Oracle to automatically decide the extent size based on the size of the corresponding segment. This mode is called “AUTOALLOCATE”, which allocates smaller extents initially (starting from 64K) but gradually increases the extent size as the object grows up to 64M. The second option, called the UNIFORM EXTENT mode, allows administrators to specify a uniform size (default 1 M) for all extents within the tablespace. Deciding which of these options to use, and when, is a topic of intense ongoing debate in the Oracle database administrator community. Most people tend to think that uniform extents are always better since it guarantees that the free extents can always be reused thereby eliminating fragmentation. However, that is not necessarily always true. For example, if a tablespace is going to be used as “scratch” area where tables of various sizes are frequently created and dropped, uniform extent sizes can lead to space wastage since each object gets at least one extent irrespective of its actual size. Also, although the extent sizes vary in the AUTOALLOCATE mode, they can still be reused since

a. All objects follow a standard extent size growth pattern b. The larger extent sizes are always multiple of smaller extent sizes

Therefore, barring exceptional circumstances, the AUTOALLOCATE mode should not result in any significant fragmentation. It is important to remember here that the fragmentation isn’t always caused just because all extents do not have the same size. The fragmentation is caused primarily when each objects follows an extent sizing policy which is different than that of other objects in the tablespace making it difficult for them to reuse any extents that it may free. Another advantage of AUTOALLOCATE is that it automatically allocates smaller extents when enough free space is not available in the data file, whereas the allocation of new extents will fail under similar situations in the UNIFORM mode. The following guideline can be used to decide which of the above mode to use depending on nature of objects residing in the tablespace

• If the objects in the tablespace are expected to vary drastically in size (i.e. some very small, other very large) or if their growth pattern is expected to be highly dynamic, and hence not known at the time of tablespace creation), using AUTOALLOCATE will prevent space wastage.

• Use UNIFORM EXTENT mode only if all objects in the database are going to be of the same size and grow in a uniform manner.

• Generally speaking, the use of AUTOALLOCATE mode should be preferred since benefits of UNIFORM extents may not be worth the hassle and risk.

BENEFITS

IMPROVED PERFORMANCE Updates to data dictionary require execution of recursive SQL. Since locally managed tablespaces perform significantly less dictionary updates, as compared to their dictionary managed counterparts, the performance of space management operation is dramatically improved. This results in overall improvement in system performance due to reduced data dictionary contention. The performance of long running queries may be improved due to more efficient management of temporary space. Data load and drop object operations should also see a similar performance enhancement.

FRAGMENTATION ELIMINATION As discussed above, locally managed tablespace eliminate the need of reorganizing objects in order to reclaim 1 A minimal set of information is still kept in the dictionary (e.g. user tablespace quota) but such updates do not generate any significant amount of undo data.

Paper # 32707

Oracle9i Database

fragmented space by following a standard extent sizing policy and automatically coalescing free space.

USING LOCALLY MANAGED TABLESPACES

CREATING LOCALLY MANAGED TABLESPACES Locally Managed Tablespace is default tablespace type in Oracle9i. That means, no additional steps need to be taken to enable this feature in Oracle9i. In prior versions, a locally managed tablespace can be created by specifying the EXTENT MANAGEMENT LOCAL [AUTOALLOCATE | UNIFORM SIZE ] clause in the CREATE TABLESPACE command.

MIGRATING DICTIONARY MANAGED TABLESPACES A dictionary managed tablespace can be converted to a locally managed tablespace using the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL() procedure. This is an online operation. Please refer to Oracle9i supplied PL/SQL packages and Types Reference for further details about how to use this procedure.

REAL WORLD IMPLEMENTATIONS

Even though Oracle continues to support dictionary managed tablespaces, locally managed tablespaces have become the preferred choice among Oracle DBAs and third part packaged application vendors. In a survey recently conducted by Oracle among 60 DBAs and consultants, approximately 70% are already using the feature. Among those who have already implemented locally managed tablespaces :

• Fragmentation was still an issue for just 3% i.e. 97% respondents didn’t have to worry about fragmentation ever since they implemented this feature.

• About 60% reported performance gains.

• No body complained of any performance degradation Likewise, a number of packaged third party application vendors such as SAP and PeopleSoft have already certified their application with locally managed tablespaces. More such certifications are under progress.

AUTOMATIC SEGMENT SPACE MANAGEMENT

MANUAL (FREELIST BASED) SPACE MANAGEMENT

In versions prior to Oracle9i, the management of free space within a segment (such as a table, index) is done using a mechanism known as freelists. A freelist, as the name itself indicates, is a list (single linked) of data blocks within the extents allocated to a given segment which could be used to insert new rows. How and when a data block gets moved on and off the freelist is determined by settings of segment properties PCTUSED and PCTFREE, both specified in terms of percentage of total space available in a block. When a new segment is created, all its blocks are on the freelist, meaning that all of them are available for accepting new data. As the data is loaded in a block, its gets moved off the freelist once the free space within the block approaches PCTFREE value. The remaining space is reserved for subsequent update to the existing data in the block. If some of data in the block is later deleted, the block is not put back on the free list until the total used space within the blocks falls just below the PCTUSED specification. By default, a segment is created with a single freelist but more of them can be added subsequently. In addition, in a Real Application Clusters (RAC) or Oracle Parallel Server (OPS) environment, one may need to create multiple freelist groups to assign a set of freelists to a specific instance. Statically assigning freelists to instances using freelist groups helps avoid movement of segment header blocks back and forth among member instances, a phenomenon commonly known as disk “pinging”, thereby improving the system performance. Multiple freelist groups also help avoid block contention by preventing different instances from trying to insert new rows in the same block. Unlike freelist, however, the number of freelist groups can only be specified at the time of object creation and cannot be altered later without recreating the object.

AUTOMATIC SEGMENT SPACE MANAGEMENT ARCHITECTURE

Oracle9i introduces a new way of managing free space within a segment using bitmaps. In the new scheme, a set of bits describes the space utilization for each block in a segment as well as whether it is formatted or not. Using these

Paper # 32707

Oracle9i Database

bits, for example, it is possible to represent the state of any given data block as follows:

• Free space in the block is less than 25%

• Free space in the block is greater than 25% and less than 50%

• Free Space in the block is greater than 50% but less than 75%

• Free space in the block is more than 75%

• The block is FULL i.e. there is no free space in the block

• The block is unformatted. It can be noted here that unlike freelists, where a block was either available for new rows or not, bitmaps provide a more granular and accurate idea of space utilization within blocks of segment. For LOBs and indexes, the bitmap just indicate

• Whether the block is formatted or not and,

• Whether the block is considered “free” or not. The Automatic Segment Space Management feature can only be used with Locally Managed Tablespaces.

BITMAP BLOCKS The bitmaps are contained in a set of meta-data blocks known as “bitmap blocks” or BMBs. The number of BMBs in a segment depends on its size and the space consumed by the bitmap blocks is typically a very small part (less than 1%) of the total segment size for any reasonable sized segment. As shown in the table below, the space overhead of bitmap blocks decreases as the segment grows and becomes close to negligible for large segments.

Segment Size Block Size No. Of BMBs Space Used by BMBs BMB Space Overhead

25 MB 2 KB 201 400 KB .8%

500 MB 8KB 251 2 MB .4%

100 TB 16KB 6555941 100 GB .05%

In order to ensure a good trade off between contention for bitmap blocks (due to small number of BMBs) and the time to required to scan a large number of bitmap blocks, the number of blocks represented by a BMB increases with the segment size. The varying density of BMBs ensures that smaller objects do not have too few BMBs and the larger ones don’t have too many. Therefore, as the segment grows, Oracle limits the growth in the number of additional BMBs by increasing the number of blocks represented by existing ones. Due to the sparse density of BMBs in small segments, the space overhead may appear to be around 5% for tables smaller than 1 M (typically used in a test/learning environment). However, as we saw above, this number should be significantly smaller in any real world environment.

SEGMENT HIGH WATER MARK (HWM) In the freelist implementation, the HWM, stored in the segment header, indicates that blocks above the HWM are unformatted and not available for insertion of new rows. The HWM is advanced five blocks each time no block is found in the freelist to insert new data.

The Automatic Segment Space Management feature allows the presence of unformatted blocks in the middle of the segment. This helps amortize the cost of formatting block over several INSERT operations, thereby improving the performance of individual operations. Leaving the blocks unformatted also gives rise to the possibility of these blocks being used by direct path load operations in the future even though they are under the high water mark. This is unlike freelist based segments where direct path load operations never use blocks below the high water mark.

The presence of unformatted blocks below the high water mark leads the Automatic Segment Space Management feature to define two types of high water marks. The Low HWM (LHWM) defines the limit below which all blocks are

Paper # 32707

Oracle9i Database

formatted whereas the High HWM (HHWM), just like HWM in freelist based segments, specifies the location above which all blocks are unformatted.

Formatted Blocks Formatted & Unformatted Blocks Unformatted Blocks

Segment Grows Low High High High Water Mark Water Mark

Figure 3: Low and High High Water Marks

The sequential read operations read the extent map for blocks under the LHWM. For blocks between LHWM and HHWM, the bitmap blocks also have to be read in order to identify the unformatted blocks.

BENEFITS

EASE OF USE The Automatic Segment Space Management feature eliminates the necessity to tune most of the space management related controls such as FREELISTS, FREELIST GROUPS and PCTUSED. This is significant because determining the optimal values of these parameters can be difficult many a times. Also, as stated earlier, changing the number of freelist groups requires the object to be recreated. Not having to adjust the number of freelist groups saves administrators from this time consuming tasks and helps them avoid the associated down time, especially when new RAC instances are brought online, thereby preventing the associated.

PERFORMANCE The Automatic Segment Space Management feature also significantly improves the performance of concurrent DML operations since different parts of the bitmap can be used simultaneously eliminating serialization for free space lookups. The performance enhancement is equally apparent for direct load operations as well since unlike freelist based segments, the blocks of a partially used extent don’t have to be formatted and put on the freelist. The table below summarizes the results of an Oracle internal test comparing the time (in seconds) required to complete a data load operation (2 million rows/process on a 4 400 MHz CPU Solaris box with 4GB RAM) with automatic and manual segment space management.

Configuration Operation No. of Concurrent Processes Out of the Box

Manual (FREELIST=1)

Tuned Manual (FREELIST =

13)

Automatic

Performance Gain in Automatic Mode

Over Tuned Manual (%)

1 33.36 33.35 34.99 -5 Conventional SQL Load

4 98.05 84.77 66.24 22

1 18.53 18.52 19.36 - 4.6 Direct Path Load

4 59.10 59.07 42.52 28

It may be noticed that while the freelist based segment marginally outperform those with Automatic Segment Space Management when only one process is accessing the segment, there are significant performance gains with Automatic Segment Space Management for higher degree of concurrency. The slight performance degradation for non-concurrent access cases is only to be expected because the Automatic Segment Space Management has been

Paper # 32707

Oracle9i Database

specifically designed to solve the problem encountered in real world environments, where segments are almost never accessed exclusively by a single operation.

The performance gains provided by this feature are even more noticeable in a Real Application Cluster environment. The chart shown below (figure 4) presents the result of another Oracle internal benchmark comparing the performance of automatic and manual segment space management. This benchmark was conducted on a two node (6 x 336 MHz CPU, 4 GB RAM per node) Real Application Cluster database by inserting about 3 million rows in a table. The Automatic Segment Space Management provided over 35% performance gain over an optimally tuned segment (8 FREELIST GROUPS, 20 FREELISTS) using the manual mode. The gains compared to out-of-box manual configuration (i.e. 1 FREELLIST and 1 FREELIST GROUP) are even more dramatic (close to 400%).

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Manual (Out of thebox)

Manual (Tuned) Auto

Row

s In

sert

ed P

er S

econ

ds

Figure 4: Performance Comparison of Manual and Automatic Segment Space Management

EFFICIENT SPACE UTILIZATION Besides enhancing manageability and performance, the Automatic Segment Space Management also improves the overall space utilization since the database now has a more accurate knowledge of how free a data block is. This enables better reuse of the available free space, especially for objects with rows of highly varying size. Oracle’s internal tests have shown the space saving to be around 15-20%, which could be quite significant for a database with several large segments.

USING AUTOMATIC SEGMENT SPACE MANAGEMENT

As said earlier, the Automatic Segment Space Management feature is available only with locally managed tablespaces. In other words, it is not possible to use this feature with dictionary managed tablespaces. It can be enabled at the time of tablespace creation using the new SEGMENT SPACE MANAGEMENT AUTO clause in the CREATE TABLESPACE command as shown below.

CREATE TABLESPACE data DATAFILE '/u02/oracle/data/data01.dbf' SIZE 50M SEGMENT SPACE MANAGEMENT AUTO; As must be apparent from the above command, Automatic Segment Space Management is a tablespace property. Therefore, all objects created in the above tablespace will use the automatic segment space management feature to manage their free space. Any specification of PCTUSED, FREELISTS and FREELIST GROUPS parameters for objects created in this tablespace will be ignored. The compatible parameter must be set to 9.0.1.3 or higher in order to use this feature.

Paper # 32707

Oracle9i Database

The option to management segment free space manually using freelist is retained in Oracle9i for backward compatibility. The SEGMENT SPACE MANAGEMENT clause of the CREATE TABLESPACE allows administrators to choose between automatic and manual modes. A tablespace created with MANUAL segment space management continues to use FREELISTS for managing free space within the objects located in it.

It is currently not possible to change the segment space management property of a tablespace after its creation. Therefore, migration of existing freelist based segment Automatic Segment Space Management involves recreating them in a locally managed tablespace with automatic segment space management. This may seem a very limiting restriction at first, but fortunately, the whole operation can be performed online using Oracle9i’s Online Table Redefinition feature. For more information on the online redefinition feature, please refer to Oracle white paper titled “Oracle9i Online Reorganization and Redefinition” at http://otn.oracle.com/deploy/availability/pdf/9i_online.pdf.

MONITORING AND TROUBLESHOOTING

A new procedure SPACE_USAGE has been added to the DBMS_SPACE package to provide information about space usage within a segment using the Automatic Segment Space Management feature. This procedure can be used to find out the number of blocks in different state of freeness (i.e. Full, 0-25% free, 25-50%, 50-75% free, 75-100%) as well the number of unformatted blocks below the HHWM. The numbers reported by this procedure do not include metadata blocks such as segment header, bitmap blocks and extent map block. Another DBMS_SPACE procedure, UNUSED_SPACE, can be used to find out the number of unformatted block above the HHWM. The “BLOCKS” column in the DBA_TABLES view provides the total number of blocks below the HHWM. The number of meta data blocks in a segment can be calculated as the difference of total number of blocks as reported by DBA_TABLES and sum of the values returned by USED_SPACE procedure. The DBMS_REPAIR package now contains a new procedure, SEGMENT_FIX_STATUS, to enable manual fixing of bitmap states in the event of any corruption. Using this procedure, the bitmap states can either be recalculated based on current contents or, set to a specified value. Besides fixing corruption, the use of the procedure SEGMNT_FIX_STATUS may also be required after changing a segment’s PCTFREE specification since the bitmap status aren’t recalculated automatically by the ALTER TABLE command.

CUSTOMER IMPLEMENTATION SUCCESS STORIES

Automatic Segment Space Management feature in conjunction with Locally Managed Tablespaces essentially removes space configuration as a cause of performance problems. Deploying these features is, therefore, is one of the key priorities for customers moving to Oracle9i. Following are some of the customers who are already done so and are enjoying the benefits of improved ease of use, more efficient space utilization, and enhanced performance.

Customer Name Business Description System/Environment Details Acxiom Global leader building and managing

data warehouses for some of the world's biggest companies, including many in the Fortune 500 (http://www.acxiom.com)

6 TB Oracle9i Release 2 Database, 15 TB Storage, 2.5 TB Raw Data

Bauer Verlagsgruppe A major German publishing group (http://www.hbv.de)

3 GB 2-node (Two IBM Netfinity 5800R systems with 4 CPUS and 4GB RAM each)RAC OLTP database serving up to 250 users

Postbank A Germany based international banking group (http://www.postbank.de)

Oracle9i Release 2 RAC running on HP-UX

CONCLUSION The space management features of Orale9i go far beyond just making the database administration easier. They also

Paper # 32707

Oracle9i Database

Paper # 32707

make the space utilization more efficient and deliver out-of-the box optimal performance. While the Automatic Undo Management feature makes the management of undo space completely transparent, locally managed tablespace and automatic segment space management together completely liberate database administrators from any kind of space related performance tuning tasks. The Oracle9i Database, therefore, makes the database administrators more productive and helps enterprises become more profitable by reducing the management costs.