Oracle is always changing, and for
the latest consensus on using
multiple blocksizes in Oracle, see
latest research on multiple
The Oracle Database Administrator's Reference 10g Release 2 (10.2) for
UNIX-Based Operating Systems notes these guidelines for choosing blocksizes
"Oracle recommends smaller Oracle Database block sizes (2
KB or 4 KB) for online transaction processing (OLTP) or mixed workload
environments and larger block sizes (8 KB, 16 KB, or 32 KB) for decision
support system (DSS) workload environments."
The Oracle 11.2
Database Performance Tuning Guide notes the advantages and
disadvantages of different blocksizes:
Block Size Advantages
- Good for small rows with lots of random access.
Reduces block contention.
- Has lower overhead, so there is more room to
- Permits reading several rows into the buffer cache with a
single I/O (depending on row size and block size).
- Good for sequential
access or very large rows (such as LOB data).
Block Size Disadvantages
- Has relatively large space overhead due to
metadata (that is, block header).
- Not recommended for large rows. There
might only be a few rows stored for each block, or worse, row chaining if a
single row does not fit into a block.
- Wastes space in the buffer cache, if you are
doing random access to small rows and have a large block size. For example,
with an 8 KB block size and 50 byte row size, you waste 7,950 bytes in the
buffer cache when doing random access.
- Not good for index blocks used
in an OLTP environment, because they increase block contention on the index
multiple blocksizes effectively requires expert-level Oracle skills and an
intimate knowledge of your I/O landscape. While deploying multiple
blocksizes can greatly reduce I/O and improve response time, it can also
wreak havoc in the hands of inexperienced DBA's. Using non-standard
blocksizes is not recommended for beginners.
For large mission-critical Oracle databases, using multiple blocksizes
can improve Oracle performance and manageability in a variety of ways:
- Contention reduction - small rows in a large block perform worse
under heavy DML than large rows in a small blocksize.
- Reduced row chaining - Placing large object rows (BLOB,
CLOB) into a tablespace space with a larger blocksize can greatly reduce row
chaining and improve I/O.
- Faster updates - Heavy insert/update tables can see faster
performance when segregated into another blocksize which is mapped to a
small data buffer cache. Smaller data buffer caches often see faster
- Reduced Pinging - RAC can perform far faster with 2K blocksizes,
greatly reducing cache fusion overhead.
- Less disk space waste - When using Oracle 11g
advanced compression, testing shows that a 32k blocksize to maximize
compression and minimize waste.
- Less RAM waste - Moving random access small row tables to a
smaller blocksize (with a corresponding small blocksize buffer) will reduce
buffer waste and improve the chance that other data blocks will remain in
- Minimize redo generation - Some experts recommend 2K
blocksizes for bitmap indexes, to minimize redo generation during bitmap
- Faster scans - Tables and indexes that require full scans can see
faster performance when placed in a large blocksize
There are many factors in choosing the best
Oracle block size, and I have my notes on Oracle block size here: