|Oracle9i Database Concepts
Release 2 (9.2)
Part Number A96524-01
This chapter describes the nature of and relationships among the logical storage structures in the Oracle server. It includes:
Oracle allocates logical database space for all data in a database. The units of database space allocation are data blocks, extents, and segments. Figure 2-1 shows the relationships among these data structures:
At the finest level of granularity, Oracle stores data in data blocks (also called logical blocks, Oracle blocks, or pages). One data block corresponds to a specific number of bytes of physical database space on disk.
The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks allocated for storing a specific type of information.
The level of logical database storage above an extent is called a segment. A segment is a set of extents, each of which has been allocated for a specific data structure and all of which are stored in the same tablespace. For example, each table's data is stored in its own data segment, while each index's data is stored in its own index segment. If the table or index is partitioned, each partition is stored in its own segment.
Oracle allocates space for segments in units of one extent. When the existing extents of a segment are full, Oracle allocates another extent for that segment. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on disk.
A segment and all its extents are stored in one tablespace. Within a tablespace, a segment can include extents from more than one file; that is, the segment can span datafiles. However, each extent can contain data from only one datafile.
Although you can allocate additional extents, the blocks themselves are allocated separately. If you allocate an extent to a specific instance, the blocks are immediately allocated to the free list. However, if the extent is not allocated to a specific instance, then the blocks themselves are allocated only when the high water mark moves. The high water mark is the boundary between used and unused space in a segment.
Oracle Corporation recommends that you manage free space automatically. See "Free Space Management".
Oracle manages the storage space in the datafiles of a database in units called data blocks. A data block is the smallest unit of data used by a database. In contrast, at the physical, operating system level, all data is stored in bytes. Each operating system has a block size. Oracle requests data in multiples of Oracle data blocks, not operating system blocks.
The standard block size is specified by the initialization parameter
DB_BLOCK_SIZE. In addition, you can specify of up to five nonstandard block sizes. The data block sizes should be a multiple of the operating system's block size within the maximum limit to avoid unnecessary I/O. Oracle data blocks are the smallest units of storage that Oracle can use or allocate.
The Oracle data block format is similar regardless of whether the data block contains table, index, or clustered data. Figure 2-2 illustrates the format of a data block.
The header contains general block information, such as the block address and the type of segment (for example, data or index).
This portion of the data block contains information about the table having rows in this block.
This portion of the data block contains information about the actual rows in the block (including addresses for each row piece in the row data area).
After the space has been allocated in the row directory of a data block's overhead, this space is not reclaimed when the row is deleted. Therefore, a block that is currently empty but had up to 50 rows at one time continues to' have 100 bytes allocated in the header for the row directory. Oracle reuses this space only when new rows are inserted in the block.
The data block header, table directory, and row directory are referred to collectively as overhead. Some block overhead is fixed in size; the total block overhead size is variable. On average, the fixed and variable portions of data block overhead total 84 to 107 bytes.
This portion of the data block contains table or index data. Rows can span blocks.
Free space is allocated for insertion of new rows and for updates to rows that require additional space (for example, when a trailing null is updated to a nonnull value). Whether issued insertions actually occur in a given data block is a function of current free space in that data block and the value of the space management parameter
In data blocks allocated for the data segment of a table or cluster, or for the index segment of an index, free space can also hold transaction entries. A transaction entry is required in a block for each
UPDATE statement accessing one or more rows in the block. The space required for transaction entries is operating system dependent; however, transaction entries in most operating systems require approximately 23 bytes.
Free space can be managed automatically or manually.
Free space can be managed automatically inside database segments. The in-segment free/used space is tracked using bitmaps, as opposed to free lists. Automatic segment-space management offers the following benefits:
You specify automatic segment-space management when you create a locally managed tablespace. The specification then applies to all segments subsequently created in this tablespace.
Two types of statements can increase the free space of one or more data blocks:
DELETE statements, and
UPDATE statements that update existing values to smaller values. The released space from these types of statements is available for subsequent
INSERT statements under the following conditions:
INSERTstatement is in the same transaction and subsequent to the statement that frees space, then the
INSERTstatement can use the space made available.
INSERTstatement is in a separate transaction from the statement that frees space (perhaps being run by another user), then the
INSERTstatement can use the space made available only after the other transaction commits and only if the space is needed.
Released space may or may not be contiguous with the main area of free space in a data block. Oracle coalesces the free space of a data block only when (1) an
UPDATE statement attempts to use a block that contains enough free space to contain a new row piece, and (2) the free space is fragmented so the row piece cannot be inserted in a contiguous section of the block. Oracle does this compression only in such situations, because otherwise the performance of a database system decreases due to the continuous compression of the free space in data blocks.
In two circumstances, the data for a row in a table may be too large to fit into a single data block. In the first case, the row is too large to fit into one data block when it is first inserted. In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment. Row chaining most often occurs with large rows, such as rows that contain a column of datatype
RAW. Row chaining in these cases is unavoidable.
However, in the second case, a row that originally fit into one data block is updated so that the overall row length increases, and the block's free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row. The rowid of a migrated row does not change.
When a row is chained or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row.
For manually managed tablespaces, two space management parameters,
PCTUSED, enable you to control the use of free space for inserts and updates to the rows in all the data blocks of a particular segment. Specify these parameters when you create or alter a table or cluster (which has its own data segment). You can also specify the storage parameter
PCTFREE when creating or altering an index (which has its own index segment).
Appendix B, "Information on Deprecated Features" for more information on the
An extent is a logical unit of database storage space allocation made up of a number of contiguous data blocks. One or more extents in turn make up a segment. When the existing space in a segment is completely used, Oracle allocates a new extent for the segment.
When you create a table, Oracle allocates to the table's data segment an initial extent of a specified number of data blocks. Although no rows have been inserted yet, the Oracle data blocks that correspond to the initial extent are reserved for that table's rows.
If the data blocks of a segment's initial extent become full and more space is required to hold new data, Oracle automatically allocates an incremental extent for that segment. An incremental extent is a subsequent extent of the same or greater size than the previously allocated extent in that segment.
For maintenance purposes, the header block of each segment contains a directory of the extents in that segment.
This chapter applies to serial operations, in which one server process parses and runs a SQL statement. Extents are allocated somewhat differently in parallel SQL statements, which entail multiple server processes.
Storage parameters expressed in terms of extents define every segment. Storage parameters apply to all types of segments. They control how Oracle allocates free database space for a given segment. For example, you can determine how much space is initially reserved for a table's data segment or you can limit the number of extents the table can allocate by specifying the storage parameters of a table in the
STORAGE clause of the
TABLE statement. If you do not specify a table's storage parameters, then it uses the default storage parameters of the tablespace.
Prior to Oracle8i, all tablespaces were created as dictionary managed. Dictionary managed tablespaces rely on data dictionary tables to track space utilization. Beginning with Oracle8i, you could create locally managed tablespaces, which use bitmaps (instead of data dictionary tables) to track used and free space. Because of the better performance and greater ease of management of locally managed tablespaces, the default for non-
SYSTEM permanent tablespaces is locally managed whenever the type of extent management is not explicitly specified.
A tablespace that manages its extents locally can have either uniform extent sizes or variable extent sizes that are determined automatically by the system. When you create the tablespace, the
AUTOALLOCATE (system-managed) clause specifies the type of allocation.
The storage parameters
STORAGE are not valid for extents that are managed locally.
Oracle uses different algorithms to allocate extents, depending on whether they are locally managed or dictionary managed.
With locally managed tablespaces, Oracle looks for free space to allocate to a new extent by first determining a candidate datafile in the tablespace and then searching the datafile's bitmap for the required number of adjacent free blocks. If that datafile does not have enough adjacent free space, then Oracle looks in another datafile.
Appendix B, "Information on Deprecated Features" for information on allocating extents in dictionary managed tables
In general, the extents of a segment do not return to the tablespace until you drop the schema object whose data is stored in the segment (using a
CLUSTER statement). Exceptions to this include the following:
ANYprivilege, can truncate the table or cluster with a
When extents are freed, Oracle modifies the bitmap in the datafile (for locally managed tablespaces) or updates the data dictionary (for dictionary managed tablespaces) to reflect the regained extents as available space. Any data in the blocks of freed extents becomes inaccessible.
for more information about deallocating extents
As long as a nonclustered table exists or until you truncate the table, any data block allocated to its data segment remains allocated for the table. Oracle inserts new rows into a block if there is enough room. Even if you delete all rows of a table, Oracle does not reclaim the data blocks for use by other objects in the tablespace.
After you drop a nonclustered table, this space can be reclaimed when other extents require free space. Oracle reclaims all the extents of the table's data and index segments for the tablespaces that they were in and makes the extents available for other schema objects in the same tablespace.
In dictionary managed tablespaces, when a segment requires an extent larger than the available extents, Oracle identifies and combines contiguous reclaimed extents to form a larger one. This is called coalescing extents. Coalescing extents is not necessary in locally managed tablespaces, because all contiguous free space is available for allocation to a new extent regardless of whether it was reclaimed from one or more extents.
Clustered tables store information in the data segment created for the cluster. Therefore, if you drop one table in a cluster, the data segment remains for the other tables in the cluster, and no extents are deallocated. You can also truncate clusters (except for hash clusters) to free extents.
Oracle deallocates the extents of materialized views and materialized view logs in the same manner as for tables and clusters.
"Materialized Views" for a description of materialized views and their logs
All extents allocated to an index segment remain allocated as long as the index exists. When you drop the index or associated table or cluster, Oracle reclaims the extents for other uses within the tablespace.
When Oracle completes the execution of a statement requiring a temporary segment, Oracle automatically drops the temporary segment and returns the extents allocated for that segment to the associated tablespace. A single sort allocates its own temporary segment in the temporary tablespace of the user issuing the statement and then returns the extents to the tablespace.
Multiple sorts, however, can use sort segments in a temporary tablespace designated exclusively for sorts. These sort segments are allocated only once for the instance, and they are not returned after the sort, but remain available for other multiple sorts.
A temporary segment in a temporary table contains data for multiple statements of a single transaction or session. Oracle drops the temporary segment at the end of the transaction or session, returning the extents allocated for that segment to the associated tablespace.
Oracle periodically checks the rollback segments of the database to see if they have grown larger than their optimal size. If a rollback segment is larger than is optimal (that is, it has too many extents), then Oracle automatically deallocates one or more extents from the rollback segment.
Appendix B, "Information on Deprecated Features" for more information on rollback segments
A segment is a set of extents that contains all the data for a specific logical storage structure within a tablespace. For example, for each table, Oracle allocates one or more extents to form that table's data segment, and for each index, Oracle allocates one or more extents to form its index segment.
Oracle databases use four types of segments, which are described in the following sections:
A single data segment in an Oracle database holds all of the data for one of the following:
Oracle creates this data segment when you create the table or cluster with the
The storage parameters for a table or cluster determine how its data segment's extents are allocated. You can set these storage parameters directly with the appropriate
ALTER statement. These storage parameters affect the efficiency of data retrieval and storage for the data segment associated with the object.
Oracle creates segments for materialized views and materialized view logs in the same manner as for tables and clusters.
Every nonpartitioned index in an Oracle database has a single index segment to hold all of its data. For a partitioned index, every partition has a single index segment to hold its data.
Oracle creates the index segment for an index or an index partition when you issue the
INDEX statement. In this statement, you can specify storage parameters for the extents of the index segment and a tablespace in which to create the index segment. (The segments of a table and an index associated with it do not have to occupy the same tablespace.) Setting the storage parameters directly affects the efficiency of data retrieval and storage.
When processing queries, Oracle often requires temporary workspace for intermediate stages of SQL statement parsing and execution. Oracle automatically allocates this disk space called a temporary segment. Typically, Oracle requires a temporary segment as a work area for sorting. Oracle does not create a segment if the sorting operation can be done in memory or if Oracle finds some other way to perform the operation using indexes.
The following statements sometimes require the use of a temporary segment:
SELECT ... ORDER BY
SELECT DISTINCT ...
SELECT ... GROUP BY
SELECT ... INTERSECT
SELECT ... MINUS
Some unindexed joins and correlated subqueries can require use of a temporary segment. For example, if a query contains a
DISTINCT clause, a
BY, and an
BY, Oracle can require as many as two temporary segments. If applications often issue statements in the previous list, the database administrator can improve performance by adjusting the initialization parameter
Oracle9i Database Reference for information on
Oracle can also allocate temporary segments for temporary tables and indexes created on temporary tables. Temporary tables hold data that exists only for the duration of a transaction or session.
Oracle allocates temporary segments differently for queries and temporary tables.
Oracle allocates temporary segments as needed during a user session in the temporary tablespace of the user issuing the statement. Specify this tablespace with a
USER or an
USER statement using the
If no temporary tablespace is defined for the user, then the default temporary tablespace is the
SYSTEM tablespace. The default storage characteristics of the containing tablespace determine those of the extents of the temporary segment. Oracle drops temporary segments when the statement completes.
Because allocation and deallocation of temporary segments occur frequently, create a special tablespace for temporary segments. By doing so, you can distribute I/O across disk devices, and you can avoid fragmentation of the
SYSTEM and other tablespaces that otherwise hold temporary segments.
Entries for changes to temporary segments used for sort operations are not stored in the redo log, except for space management operations on the temporary segment.
Chapter 22, "Controlling Database Access" for more information about assigning a user's temporary segment tablespace
Oracle allocates segments for a temporary table when the first
INSERT into that table is issued. (This can be an internal insert operation issued by
SELECT.) The first
INSERT into a temporary table allocates the segments for the table and its indexes, creates the root page for the indexes, and allocates any
Segments for a temporary table are allocated in the temporary tablespace of the user who created the temporary table.
Oracle drops segments for a transaction-specific temporary table at the end of the transaction and drops segments for a session-specific temporary table at the end of the session. If other transactions or sessions share the use of that temporary table, the segments containing their data remain in the table.
Automatic undo management is undo-tablespace based. You allocate space in the form of a few undo tablespaces, instead of allocating many rollback segments in different sizes.
Oracle9i Database Administrator's Guide for information about creating an undo tablespace
Automatic undo management lets you explicitly control undo retention. Through the use of a system parameter (
UNDO_RETENTION), you can specify the amount of committed undo information to retain in the database. You specify the parameter as clock time (for example, 30 seconds). With retention control, you can configure your system to enable long queries to run successfully.
V$UNDOSTAT view to monitor and configure your database system to achieve efficient use of undo space.
V$UNDOSTAT shows various undo and transaction statistics, such as the amount of undo space consumed in the instance.
In earlier releases, undo space management was performed using rollback segments. This method is now called manual undo management mode.
Undo mode provides a more flexible way to migrate from manual undo management to automatic undo management. A database system can run in either manual undo management mode or automatic undo management mode. In manual undo management mode, undo space is managed through rollback segments. Manual undo management mode is supported under any compatibility level. Use it when you need to run Oracle9i to take advantage of some new features, but are not yet not ready to convert to automatic undo management mode.
In automatic undo management mode, undo space is managed in undo tablespaces. To use automatic undo management mode, the database administrator needs only to create an undo tablespace for each instance and set the
UNDO_MANAGEMENT initialization parameter to
AUTO. Automatic undo management mode is supported under compatibility levels of Oracle9i or higher. Although manual undo management mode is supported, you are strongly encouraged to run in automatic undo management mode.
In automatic undo management mode, the system controls exclusively the assignment of transactions to undo segments, and controls space allocation for undo segments. An ill-behaved transaction can potentially consume much of the undo space, thus paralyzing the entire system. In manual undo management mode, you can control such possibilities by limiting the size of rollback segments with small
MAXEXTENTS values. However, you then have to explicitly assign long running transactions to larger rollback segments, using the
SEGMENT statement. This approach has proven to be cumbersome.
The Resource Manager directive
UNDO_POOL is a more explicit way to control large transactions. This lets database administrators group users into consumer groups, with each group assigned a maximum undo space limit. When the total undo space consumed by a group exceeds the limit, its users cannot make further updates until undo space is freed up by other member transactions ending.
The default value of
UNLIMITED, where users are allowed to consume as much undo space as the undo tablespace has. Database administrators can limit a particular user by using the
Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions.
Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. A database administrator can specify a retention period by using the parameter
UNDO_RETENTION. For example, if
UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the
OER error, "snapshot too old."
You can either set
UNDO_RETENTION at startup or change it dynamically with the
SYSTEM statement. The following example sets retention to 20 minutes:
If you do not set the
UNDO_RETENTION parameter, then Oracle uses a small default value that should be adequate for most OLTP systems, where queries are not usually not very long.
In general, it is a good idea not to set retention to a value very close to what the undo tablespace can support, because that may result in excessive movement of space between undo segments. A 20% buffer of undo space is recommended.
Monitor transaction and undo information with
V$ROLLSTAT. For automatic undo management, the information in
V$ROLLSTAT reflects the behaviors of the automatic undo management undo segments.
V$UNDOSTAT view displays a histogram of statistical data to show how well the system is working. You can see statistics such as undo consumption rate, transaction concurrency, and lengths of queries run in the instance. Using this view, you can better estimate the amount of undo space required for the current workload. This view is available in both the automatic undo management and manual undo management mode.
Oracle9i Database Administrator's Guide for more details about using