Oracle Segment Header Internals: Managing Free Blocks, Extents, and the High Water Mark

When Oracle places rows into data blocks, it relies on the segment header to coordinate where those rows go and which blocks are available to receive them. The segment header block is the first block of any Oracle table or index segment. It contains control information about free blocks, the high water mark, and the extent map for the segment — the three core elements of Oracle's internal space management architecture.

Understanding the segment header is a prerequisite for diagnosing buffer busy waits, tuning PCTFREE and PCTUSED, and deciding when Automatic Segment Space Management (ASSM) provides a measurable performance advantage over manual freelist management.

Every Oracle data block has five internal components. The segment header uses knowledge of these components — particularly the free space and row data areas — to decide which blocks to place on freelists.

The header, table directory, and row directory together consume a small percentage of each block. The bulk of each block is divided between free space and row data, and it is this division that PCTFREE, PCTUSED, and the freelist structures in the segment header govern.

When a database is created, Oracle divides storage into logical units called tablespaces. The SYSTEM tablespace is created first. The SYSAUX tablespace is created automatically as part of every Oracle database from Oracle 10g onward; starting with Oracle Database 11g it is a required component. Additional tablespaces separate table data, index data, undo segments, and temporary segments. Tablespaces can be renamed using the RENAME TO clause of the ALTER TABLESPACE command.

Each tablespace is backed by one or more datafiles. Datafiles allocate their full specified size at creation time. A single datafile belongs to exactly one tablespace. Datafiles can be configured for automatic extension using AUTOEXTEND ON, with a configurable increment size and a maximum size cap to prevent uncontrolled disk consumption.

A user schema is a named collection of logical database objects — tables, indexes, sequences, views — that map to physical storage in tablespaces. A schema's objects can span multiple tablespaces, and a single tablespace can hold objects from multiple schemas.

When a table or index is created, Oracle assigns it to a tablespace and creates a segment in that tablespace to hold its data. A segment is composed of extents: contiguous sets of Oracle data blocks. When existing extents can no longer hold new rows, Oracle allocates another extent. Multiple extents within a segment are not guaranteed to be physically contiguous on disk.

Tablespaces can be locally managed (the default since Oracle 9i) or dictionary managed. Locally managed tablespaces track extent allocation in a bitmap within the tablespace header files, eliminating the recursive data dictionary SQL and contention associated with dictionary-managed tablespaces. When you create a tablespace, the default storage parameters you specify apply to every object created in that tablespace unless explicitly overridden at CREATE TABLE or CREATE INDEX time.

Extent metadata for a specific segment is stored in two places:

1. The data dictionary — accessible via DBA_EXTENTS and DBA_SEGMENTS
2. The segment header block itself — as an internal extent map

If a segment grows beyond a threshold number of extents (determined by block size and platform), Oracle creates additional extent map blocks within the segment to track the overflow. Managing the space consumed by tablespaces, datafiles, segments, and database objects is one of the primary responsibilities of the DBA.

All Oracle table and index segments use freelists to track which blocks are available for INSERT operations. Freelists are internal structures embedded in the segment header. They cannot be directly queried or modified, and are never visible to the DBA. The only user-facing parameters that influence freelist behavior are FREELISTS and FREELIST GROUPS, specified at CREATE TABLE or CREATE INDEX time.

A freelist is a singly linked list of block pointers. The segment header points to the first free block; each free block contains a forward pointer to the next free block in the chain. Oracle follows this chain to locate a block with sufficient free space for an incoming INSERT row.

Oracle maintains five distinct freelist structures within the segment header. The following diagram illustrates the high water mark, extents table, and all freelist types in a single reference.

1. Master freelist: the central list of free blocks for the segment, stored in block #1 of the segment header. When a process needs a free block and its process freelist is empty, Oracle acquires blocks from the master freelist in increments of five blocks.
2. Super master freelist: used in Oracle Parallel Server (OPS) environments. Block #1 of the segment holds a super master freelist that coordinates multiple master freelists, one per freelist group. See the OPS and RAC note below.
3. Freelist groups: in non-ASSM environments with multiple parallel server processes, each group has its own master freelist. Each parallel server process is assigned to a freelist group to reduce contention on the segment header block.
4. Process freelist: a per-process list created when the FREELIST parameter is set at CREATE TABLE or CREATE INDEX time. A process freelist acquires blocks from the master freelist in five-block increments. Blocks are also added to a process freelist when a DELETE operation frees space or when a freelist merge occurs. Each update process reads only its own process freelist; a block that appears on one process freelist is not visible to other processes.
5. Transaction freelist: allocated on demand as transactions require block access. When a transaction completes or commits, its freelist entries transfer to the process freelist. The most recently freed blocks are added to the head of the freelist chain.

With Oracle Parallel Server (OPS), block #1 of each segment holds a super master freelist in addition to the per-group master freelists. The super master freelist coordinates space allocation across all freelist groups.

Modern equivalent: Oracle Parallel Server was superseded by Oracle Real Application Clusters (RAC) in Oracle 9i. RAC introduced Cache Fusion, which shares data blocks between cluster nodes in memory via the high-speed interconnect, eliminating the disk-based block coordination that OPS required. In a RAC environment running ASSM tablespaces, the bitmap-based space management replaces manual freelist groups entirely. The OPS super master freelist concept is presented here for historical completeness and for understanding legacy schemas; new deployments on Oracle RAC with ASSM have no need for manual freelist group configuration.

The high water mark (HWM) is the boundary in a segment beyond which no block has ever been formatted for data. When an INSERT request cannot be satisfied by any existing freelist entry, Oracle raises the HWM by five blocks and adds those blocks to the master freelist. The master freelist is incremented by five blocks each time the HWM advances.

All blocks above the HWM are automatically eligible to receive rows. All blocks below the HWM must appear on a freelist to be available for INSERT operations. A block below the HWM that is not on any freelist — because it is full, or because a DELETE returned its space but the block was never re-linked — cannot receive new rows until a freelist re-link occurs or a full table scan reclaims it.

1. Freelist merge: a process freelist may acquire blocks when a freelist merge occurs. A freelist merge happens after the master freelist has been incremented; Oracle moves five-block increments from the master freelist to the requesting process freelist.
2. Transaction freelist: allocated on an as-needed basis. Transaction entries transfer to the process freelist after the transaction commits or ends. The most recently freed blocks move to the head of the freelist chain, making them immediately available for the next INSERT.

The extents table is an internal structure within the segment header that tracks all extents allocated to the segment and directs Oracle to the correct extent when the HWM advances beyond the current extent boundary. When a segment requires a new extent, Oracle consults the extents table to locate the next pre-allocated extent or to trigger a new extent allocation.

Segment header contention occurs when multiple sessions compete for the same segment header block, producing buffer busy waits and ITL (Interested Transaction List) entry contention. It is most common in high-concurrency OLTP environments with frequent INSERT or UPDATE activity concentrated on a single table or index.

Prior to Oracle 9i, buffer busy waits on the segment header were a significant scalability bottleneck. Without ASSM, every INSERT session had to visit the segment header block to acquire a free block pointer from the single master freelist. Under high concurrency, sessions serialized on this single block. ASSM replaced the freelist chain with a multi-level bitmap: different processes update different bitmap regions simultaneously, eliminating the single-point serialization for free block lookups.

Strategies to reduce segment header contention in current Oracle versions:

1. Monitor with AWR and ASH: Use AWR reports, Active Session History data, and dynamic performance views V$WAITSTAT and V$SESSION_WAIT to identify contention. Key wait events are buffer busy waits and enq: TX - allocate ITL entry.
2. Enable ASSM: Create tablespaces with SEGMENT SPACE MANAGEMENT AUTO. Oracle manages block-level free space using a bitmap in the segment header, eliminating the need to configure PCTUSED or manual freelist groups.
3. Increase INITRANS: INITRANS sets the initial number of ITL entries per block. For tables or indexes with high concurrent DML, set a higher INITRANS value at CREATE TABLE or CREATE INDEX time. Oracle allocates additional ITL entries dynamically up to MAXTRANS, but only from within the block's free space; pre-allocating via INITRANS avoids contention on busy blocks.
4. Use partitioning: Distributing a large table across multiple partitions divides segment header load across multiple partition segments, allowing parallel DML to proceed against separate segment headers.
5. Reverse key indexes: For indexes on monotonically increasing keys (sequence-based primary keys, timestamps), reverse key indexes redistribute insertions across all leaf blocks, reducing hot-block contention at the right-most index block.
6. Freelist groups (non-ASSM only): Assign parallel server processes to separate freelist groups so each process manages space allocation independently.
7. Application-level optimization: Reduce concurrent DML frequency on hot objects through batch processing, bulk binds, sequence caching, or application-tier object partitioning.
8. Transaction isolation level: READ COMMITTED (Oracle's default) allows non-blocking reads and reduces ITL contention compared to SERIALIZABLE isolation, which holds more locks for longer.

The segment header coordinates all space management activity for a table or index segment through five internal structures: the master freelist, super master freelist (OPS/legacy), freelist groups, process freelists, and transaction freelists. These structures interact with PCTFREE, PCTUSED, INITRANS, and the high water mark to determine where rows are placed, when blocks become available for reuse, and how concurrent DML is serialized or distributed across processes.

Key rules to carry forward:

• PCTFREE controls freelist un-link: when a block reaches the PCTFREE threshold during INSERT activity, it leaves the freelist.
• PCTUSED controls freelist re-link: when used space drops below PCTUSED, the block rejoins the freelist for new INSERT operations.
• Each update process reads only its own process freelist; a block appears on exactly one process freelist at a time.
• The HWM advances in five-block increments when no freelist entry can satisfy an INSERT request.
• In ASSM tablespaces, the bitmap replaces all manual freelist structures, and PCTUSED has no effect.

The next lesson covers how to set PCTFREE for optimal performance. Before proceeding, review the foundational concepts at the link below.

Data Block Fundamentals