WHAT IS THE DB_FILE_MULTIBLOCK_READ_COUNT PARAMETER? [ID 1037322.

6]
Modified 18-AUG-2010 Type FAQ Status PUBLISHED

Applies to:

Oracle Server - Enterprise Edition

Oracle Server - Enterprise Edition - Version: 7.0.16.0 and later [Release: 7.0 and later]
Information in this document applies to any platform.
Platform: All
Platform versions: All
Products: RDBMS
RDBMS Versions: 7.x - 9.x
Information type: Advisory
Impact: High
Distribution: Public
Subject Area: Performance Tuning

Purpose

This document discusses the DB_FILE_MULTIBLOCK_READ_COUNT parameter, and its

suggested usage and restrictions.

Questions and Answers

WHAT IS DB_FILE_MULTIBLOCK_READ_COUNT?
======================================

The db_file_multiblock_read_count initialization parameter determines the

maximum number of database blocks read in one I/O operation during a full
table scan. The setting of this parameter can reduce the number of I/O calls
required for a full table scan, thus improving performance.

While it may be tempting to set a very high value for

db_file_multiblock_read_count to improve overall performance, you must
consider several factors before doing so. This is discussed below.

HOW DOES IT WORK?

=================

I/O is a function of the operating system and so there are operating system
specific limits imposed on the setting of this parameter. Oracle's ability to
read multiple blocks is limited by the operating system's upper limit on the
number of bytes which can be read in a single I/O call (MAX_IO_SIZE). If the
value of db_file_multiblock_read_count exceeds internal constraints on the
setting, it will default to the O/S default: (max_IO_size / db_block_size).
Consult your operating specific documentation for limits and default values of
the maximum I/O size.

The setting of db_file_multiblock_read_count dictates how many I/O calls will

be required to complete a table scan. For example, if
db_file_multiblock_read_count is set to 32, and the Oracle block size = 8k,
then a sequential scan of a 256k table can be read in one pass. This improves
the speed of the table scan and overall query performance.
TUNING ANALYSIS
===============

The total number of I/Os actually required to perform a full table scan
depends on other factors such as the size of the table and whether parallel
query is being used. The cost-based optimizer uses all of these factors,
including db_file_multiblock_read_count to determine the cost of full table
scans. Cost-based optimizer will favor full table scans when the cost is lower
than index scans.

The Explain Plan for a given query will reveal if a full table scan will be
performed. The BSTAT/ESTAT report lists statistics for multi-block reads as
"db file scattered read". The term "scattered read" refers to multiple blocks
read into DB block buffers that are "scattered" throughout memory. High
values for db file scattered read is often an indicator of many full table
scans being performed. BSTAT/ESTAT is a useful tool in tuning this and other
init.ora parameters.

The goal of setting the db_file_multiblock_read_count parameter is that table

scans are performed in fewer, larger I/Os. This is done by evaluating the
number of blocks required to complete each table scan over time, then
adjusting the parameter so that on average, most scans can be performed in one
I/O. Database tuning is an iterative process which is done through careful
analysis of application performance measured by TKPROF and database statistics
provided by BSTAT/ESTAT and dynamic performance views, such as v$sysstat and
v$sesstat.

LIMITATIONS
===========

The following are some important considerations for setting

DB_FILE_MULTIBLOCK_READ_COUNT:

It is extremely important to know your applications in order to determine the

best setting for db_file_multiblock_read_count. For example, Online
Transaction Processing (OLTP) applications which seldom perform full table
scans will not benefit from a high value for db_file_multiblock_read_count,
and in fact may suffer performance degradation since the cost-based optimizer
may favor a full table scan in some cases when the relative cost is determined
to be less due to reading multiple blocks.

If db_file_multiblock_read_count is set too low, additional I/O will be

required to perform sequential table scans when the table does not qualify as
a short table. A short table is a table consisting of less than 5 Oracle
blocks. A long table spans 5 or more Oracle blocks. An in-depth analysis of
the database tables and applications is necessary. This parameter is subject
to operating system limitations, and changes from the default value should
only be made after consulting Oracle Operating Specific documentation.

The cost of setting db_file_multiblock_read_count too high is that the server

will consume additional memory and may cause full table scans to be chosen by
the Cost-Based Optimizer more frequently.

The maximum value of the overall multiblock read factor is calculated as:

(db_block_size * db_file_multiblock_read_count)

The value of db_file_multiblock_read_count is limited by the multiblock

read factor in the operating system level.
Regardless of the MAX_IO_SIZE value allowed by your operating system,
db_file_multiblock_read_count cannot exceed:

(db_block_buffers/4)

NOTE: Benchmarks of values higher than 32 have shown little, if any

performance gain.

WARNINGS and CONSIDERATIONS

===========================

On HP/UX RDBMS version 7.3.3.0, if the product

(db_block_size * db_file_multiblock_read_count)

exceeds 64K, a core dump and ORA-7445 can occur. This is corrected by
reducing the value of db_file_multiblock_read_count and restarting the
instance.

The following bugs have been logged for this problem on HP/UX version 7.3.3.0,
and are fixed in 7.3.3.3:

505464
509726
516642

Patch 433762 on version 7.3.2 for Solaris allows a setting of

db_file_multiblock_read_count = 128 for 8k db_block_size.

REFERENCES:
===========

Oracle7 Server Tuning

Oracle8i Tuning

Note:30712.1 Init.ora parameter "DB_FILE_MULTIBLOCK_READ_COUNT" Reference note

References

BUG:433762 - DB_FILE-MULTIBLOCK_READ_COUNT CAN NOT BE CHANGED. KEEPS

DEFAULTING TO 16K
BUG:505464 - SMON CRASHES WITH ORA-7445 [11] AFTER UPGRADE TO 7.3.3
BUG:509726 - ORA-7445 [4][9][0] WHEN TRYING TO QUERY DBA_TABLESPACES
BUG:516642 - ORA-07445: EXCEPTION ENCOUNTERED: CORE DUMP [11] [0] [0] [0] []