As explained in "Logical Space Management", Oracle Database manages segment space automatically or manually. This section assumes the use of ASSM.
User Segments
A single data segment in a database stores the data for one user object. There are different types of segments. Examples of user segments include:
■Table, table partition, or table cluster
■LOB or LOB partition
■Index or index partition
Each nonpartitioned object and object partition is stored in its own segment. For example, if an index has five partitions, then five segments contain the index data.
User Segment Creation
By default, the database uses deferred segment creation to update only database metadata when creating tables and indexes. Starting in Oracle Database 11g Release 2 (11.2.0.2), the database
also defers segment creation when creating partitions. When a user inserts the first row into a table or partition, the database creates segments for the table or partition, its LOB columns, and its indexes.
Deferred segment creation enables you to avoid using database resources unnecessarily. For example, installation of an application can create thousands of objects, consuming significant
disk space. Many of these objects may never be used.
You can use the DBMS_SPACE_ADMIN package to manage segments for empty objects. Starting with Oracle Database 11g Release 2 (11.2.0.2), you can use this PL/SQL package to do the following:
■Manually materialize segments for empty tables or partitions that do not have segments created
■Remove segments from empty tables or partitions that currently have an empty segment allocated
To best illustrate the relationship between object creation and segment creation, assume that deferred segment creation is disabled. You create a table as follows:
When you create a table with a primary key or unique key, Oracle Database automatically creates an index for this key. Again
assume that deferred segment creation is disabled. You create a table as follows:
CREATE TABLE lob_table (my_column NUMBER PRIMARY KEY, clob_column CLOB);
Figure 12–19 shows that the data for lob_table is stored in one segment, while the implicitly created index is in a different segment. Also, the CLOB data is stored in its own segment,
as is its associated CLOB index (see "Internal LOBs" on page 19-12). Thus, the CREATE TABLE statement results in the creation of four different segments.
The database allocates one or more extents when a segment is created. Storage parameters for the object determine how the
extents for each segment are allocated (see "Storage Parameters for Extents" on page 12-20). The parameters affect the efficiency of data retrieval and storage for the data segment associated with the object.
Temporary Segments
When processing a query, Oracle Database often requires temporary workspace for intermediate stages of SQL statement execution. Typical operations that may require a temporary segment
include sorting, hashing, and merging bitmaps. While creating an index, Oracle Database also places index segments into temporary segments and then converts them into permanent segments when the index is complete.
Oracle Database does not create a temporary segment if an operation can be performed in memory. However, if memory use is not possible, then the database automatically allocates a temporary
segment on disk.
Allocation of Temporary Segments for Queries
Oracle Database allocates temporary segments for queries as needed during a user session and drops them when the query completes. Changes to temporary segments are not recorded in the
online redo log, except for space management operations on the temporary segment (see "Overview of the Online Redo Log" on page 11-12).
The database creates temporary segments in the temporary tablespace assigned to the user. The default storage characteristics of the tablespace determine the characteristics of the extents in the temporary segment. Because allocation and deallocation of temporary
segments occurs frequently, the best practice is to create at least one special tablespace for temporary segments. The database distributes I/O across disks and avoids fragmenting SYSTEM and other tablespaces with temporary segments.
Note:
When SYSTEM is locally managed, you must define a default temporary tablespace at database creation. A locally managed SYSTEM tablespace cannot be used for default temporary storage.
Allocation of Temporary Segments for Temporary Tables and Indexes
Oracle Database can also allocate temporary segments for temporary tables and their indexes. Temporary tables hold data that
exists only for the duration of a transaction or session. Each session accesses only the extents allocated for the session and cannot access extents allocated for other sessions.
Oracle Database allocates segments for a temporary table when the first INSERT into that table occurs. The insertion can occur explicitly or because of CREATE TABLE AS 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 LOB segments.
Segments for a temporary table are allocated in a temporary tablespace of the current user. Assume that the temporary tablespace
assigned to user1 is temp1 and the temporary tablespace assigned to user2 is temp2. In this case, user1 stores temporary data in the temp1 segments, while user2 stores temporary data in the temp2 segments.
Undo Segments
Oracle Database maintains records of the actions of transactions, collectively known as undo data. Oracle Database uses undo
to do the following:
■Roll back an active transaction
■Recover a terminated transaction
■Provide read consistency
■Perform some logical flashback operations
Oracle Database stores undo data inside the database rather than in external logs. Undo data is stored in blocks that are
updated just like data blocks, with changes to these blocks generating redo. In this way, Oracle Database can efficiently access undo data without needing to read external logs.
Undo data is stored in an undo tablespace. Oracle Database provides a fully automated mechanism, known as automatic undo management mode, for managing undo segments and space in an undo
tablespace.
Undo Segments and Transactions
When a transaction starts, the database binds (assigns) the transaction to an undo segment, and therefore to a transaction table, in the current undo tablespace. In rare circumstances,
if the database instance does not have a designated undo tablespace, then the transaction binds to the system undo segment.
Multiple active transactions can write concurrently to the same undo segment or to different segments. For example, transactions T1 and T2 can both write to undo segment U1, or T1 can
write to U1 while T2 writes to undo segment U2.
Conceptually, the extents in an undo segment form a ring. Transactions write to one undo extent, and then to the next extent in the ring, and so on in cyclical fashion. Figure 12–20
shows two transactions, T1 and T2, which begin writing in the third extent (E3) of an undo segment and continue writing to the fourth extent (E4).
Transaction Rollback
When a ROLLBACK statement is issued, the database uses undo records to roll back changes made to the database by the uncommitted transaction. During recovery, the database rolls back
any uncommitted changes applied from the online redo log to the data files. Undo records provide read consistency by maintaining the before image of the data for users accessing data at the same time that another user is changing it.
