Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








ASSM, freelists and PCTFREE

Oracle Database Tips by Donald Burleson

Oracle introduced Automatic Segment Storage Management (ASSM) as a replacement for traditional freelists management which used one-way linked-lists to manage free blocks with tables and indexes.  ASSM is commonly called "bitmap freelists" because that is how Oracle implement the internal data structures for free block management.  Do not confuse ASSM (bitmap freelists) with Automatic Storage Management (ASM). 

As of Oracle 10g, BC does not always recommend implementing bitmap freelists for high DML tables because there is a tradeoff between reduced buffer busy waits and DML contention during high update activity.

Note: As of 11g release 2, many of the performance bugs in ASSM have been repaired.  However, it is still important to test ASSM if you use it for tables that experience high-volume DML updates.

The bitmap freelists of ASSM greatly reduce segment header contention and improve simultaneous insert concurrency (up to a point).  ASSM also removes the need to specify freelist groups in RAC.  The new dbms_space procedures allow the DBA to see growth trends within specific objects, and ASSM provides better multi-instance RAC behavior in terms of performance/space utilization.

Simpler object management with ASSM

ASSM provides administrative ease of use by avoiding the specification of storage parameters and ASSM is a very efficient method for handling objects with varying row sizes. Lastly, ASSM provides better run-time adjustment for variations in concurrent access and avoids tedious tuning methods.

Why use ASSM?

Automatic segment space management (ASSM) is a simpler and more efficient way of managing space within a segment. It completely eliminates any need to specify and tune the pctused, freelists, and freelist groups storage parameters for schema objects created in the tablespace. If any of these attributes are specified, they are ignored.  ASSM is not for every database, especially those with super-high DML rates:

Pros of ASSM:

Varying row sizes: ASSM is better than a static pctused. The bitmaps make ASSM tablespaces better at handling rows with wide variations in row length.

Reducing buffer busy waits: ASSM will remove buffer busy waits better than using multiple freelists. When a table has multiple freelists, all purges must be parallelized to reload the freelists evenly, and ASSM has no such limitation.

Great for Real Application Clusters: The bitmap freelists remove the need to define multiple freelists groups for RAC and provide overall improved freelist management over traditional freelists.

Cons of ASSM:

Slow for full-table scans: Several studies have shown that large-table full-table scans (FTS) will run longer with ASSM than standard bitmaps. ASSM FTS tablespaces are consistently slower than freelist FTS operations. This implies that ASSM may not be appropriate for decision support systems and warehouse applications unless partitioning is used with Oracle Parallel Query.

Slower for high-volume concurrent inserts: Numerous experts have conducted studies that show that tables with high volume bulk loads perform faster with traditional multiple freelists.

ASSM will influence index clustering: For row ordered tables, ASSM can adversely affect the clustering_factor for indexes. Bitmap freelists are less likely to place adjacent tows on physically adjacent data blocks, and this can lower the clustering_factor and the cost-based optimizer's propensity to favor an index range scan.

According to Oracle benchmarks, using bitmap FREELISTS removes all segment header contention and allows for super-fast concurrent insert operations:

For each extent in the segment, Oracle ASSM keeps an entry pointing to the bitmap for that segment:

ASSM Segment header extent map points to all extent bitmaps in segments.

Oracle ASSM also has pointers to the last bitmap block within each logical bitmap level:

ASSM has 6 different status flags for table blocks:

0 = unformatted
1 = logically full (per pctfree)
2 = 0-25% free
3 = 25-50% free
4 = 50%-75% free
5= 75-100% free

As rows are inserted, ASSM updates his ?level 1 bitmap block? when the new free space crosses one of these six thresholds. It's also important to note that blocks are marked as full as soon as the last insert/update crosses the PCTFREE threshold, the point at which ASSM un-links the data block from the freelist chain.

For example, assume the default PCTFREE=20, which specifies an freelist unlink when the block is 80% full. Whether an insert takes the ?real? free space to 81% or 99%, Oracle marks the block as full, without regard to the amount of fullness.

Hence you cannot assume that the ?real? free space kept in reserve for row expansion is 20%; it depends on several factors, most notably the block size and average row length for the table.

Adjusting the behavior of ASSM (guru's only)

According to Oracle expert Tanel Poder, there are some undocumented hidden parameters in ASSM to control it's behavior: (Note: Never change hidden parameters without the consent of Oracle Technical Support):

  • _walk_insert_treshold (default 5)
    Freelist blocks to scan before turning to higher level list or bump HWM (if walking on TFL, PFL and MFL are searched next)
  • _release_insert_threshold (default 5)
    How many unsuitable blocks to unlink from freelist before bump HWM

See my other notes on ASSM here:

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.