Oracle Consulting Oracle Training Oracle Support Development
Oracle Books
SQL Server Books
IT Books
Job Interview Books
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle


Privacy Policy




Oracle Tips by Burleson 

Oracle Performance and disk I/O

When a request is made from the Oracle database to fetch a block from a disk, we see sources of latency. This example assumes that we are not using a disk array with caching, and that a physical I/O is required to fetch the data block. When a physical request is made to a disk, the total delay time can be broken into three components:

* Seek delay (70%) -- the seek delay is the amount of time it takes to move the read-write heads over the appropriate cylinder on the disk device. Seek delay is the largest component of disk delay.
* Rotational delay (30%) -- Rotational delay is the time that the I/O must wait for the requested block to pass beneath the read-write heads. The average rotational delay for a disk is one-half the rotational speed of the disk.
* Transmission delay (<1%) -- is the smallest component of Oracle disk response time, and the only one that relates to block size. Transmission time is measured at the speed of light, and the overhead of transmitting a 32k block is not measurable slower than fetching a 2k block.

Once we understand that 99% of the disk delay is required whether we read a 2K block or a 32K block, we begin to understand the nature of disk I/O and block sizing.

The seek delay and rotational delay are the same regardless of the size of the block you are reading, and that transmission time differences are so small as to be un-measurable. Once the read-write heads are positioned directly over the cylinder, the only difference in machinery sources is the time required to transmit the larger block across the network back to the Oracle database.

Hence, we can come to an important conclusion:

The database block size does not measurably affect the speed of the block I/O, and fetching a 32K block is not more expensive than fetching a 2K block.

If it takes about the same amount of time to fetch a 2k block as it does to fetch a 32k block, why don’t we make all of our database blocks 32K and get as more data for the same I/O cost?

The answer is the expense of potentially wasted RAM storage in the data buffer caches. For example, moving a 32K block into the RAM buffer to retrieve an 80-byte record is a huge waste, unless there are other rows in the 32K block that are like to be requested by Oracle. Our goal is to manage our precious RAM space and make the most efficient use of our data buffer caches.

While the general rule holds true that the more data you can fetch a single I/O, the better your overall buffer hit ratio, we have to take a closer look at the multiple data buffer phenomenon to gather true picture of what's happening under the covers. Let’s start with a simple example.

The above is an excerpt from the "Oracle9i UNIX Administration Handbook" by Oracle press, authored by Donald K. Burleson.


Download your Oracle scripts now:

The definitive Oracle Script collection for every Oracle professional DBA



Linux Oracle commands syntax poster

ION Oracle tuning software

Oracle data dictionary reference poster

Oracle Forum

BC Oracle consulting support training

BC remote Oracle DBA   



 Copyright © 1996 -2017 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks

Hit Counter