The Freelists Parameter and DML Performance
Oracle Tips by Burleson Consulting
The freelists parameter tells Oracle
how many segment header blocks to create for a table or index.
Multiple freelists are used to prevent segment header contention
when several tasks compete to insert, update, or
delete from the table. The freelists parameter should be
set to the maximum number of concurrent update operation.
TIP - Prior to Oracle8i, you must
reorganize the table to change the freelists storage
parameter. In Oracle8i, you can dynamically add freelists to
any table or index with the alter table command, as long as
the compatibility parameter is set to at least 8.1.6. In
Oracle8i, adding a freelist reserves a new block in the table
to hold the control structures.
The freelist groups Storage Parameter for OPS
The freelist groups parameter is used
in Oracle Parallel Server (renamed Real Application Clusters in
Oracle9i). When multiple instances access a table, separate
freelist groups are allocated in the segment header. The freelist
groups parameter should be set the number of instances that
access the table.
Note: The variables are called pctfree and
pctused in the create table and alter table
syntax, but they are called PCT_FREE and PCT_USED in the
Remote DBA_tables view in the Oracle dictionary. The programmer
responsible for this mix-up was promoted to senior vice president in
recognition of his contribution to the complexity of the Oracle
Summary of Storage Parameter Rules
The following rules govern the settings for
the storage parameters freelists, freelist groups,
pctfree, and pctused. As you know, the value of
pctused and pctfree can easily be changed at any time
with the alter table command, and the observant Remote DBA should be
able to develop a methodology for deciding the optimal settings for
these parameters. For now, accept these rules, and I will discuss
them in detail later in this chapter.
There is a direct trade-off between effective
space utilization and high performance, and the table storage
parameters control this trade-off:
For efficient space reuse
A high value for pctused will effectively reuse space on
data blocks, but at the expense of additional I/O. A high
pctused means that relatively full blocks are placed on the
freelist. Hence, these blocks will be able to accept only a few
rows before becoming full again, leading to more I/O.
For high performance A low
value for pctused means that Oracle will not place a data
block onto the freelist until it is nearly empty. The block will
be able to accept many rows until it becomes full, thereby
reducing I/O at insert time. Remember that it is always faster for
Oracle to extend into new blocks than to reuse existing blocks. It
takes fewer resources for Oracle to extend a table than to manage
While we will go into the justification for
these rules later in this chapter, let’s review the general
guidelines for setting of object storage parameters:
Always set pctused to allow enough
room to accept a new row. We never want to have free blocks that
do not have enough room to accept a row. If we do, this will cause
a slowdown, since Oracle will attempt to read five “dead” free
blocks before extending the table to get an empty block.
The presence of chained rows in a table means
that pctfree is too low or that db_block_size
is too small. In most cases within Oracle, RAW and LONG RAW
columns make huge rows that exceed the maximum block size for
Oracle, making chained rows unavoidable.
If a table has multiple simultaneous
insert SQL processes, it needs to have multiple simultaneous
Running a single purge job will place all of
the free blocks on only one freelist, and none of the other
freelists will contain any free blocks from the purge.
The freelist parameter should be set
to the high-water mark of updates to a table. For example, if the
customer table has up to 20 end users performing insert
operations at any time, the customer table should have
The freelist groups parameter should
be set the number of Oracle Parallel Server instances that access
This is an excerpt from "Oracle High-Performance SQL Tuning" by
Donald K. Burleson, published by Oracle Press.