| |
 |
|
ss
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.
|
Download your Oracle scripts now:
www.oracle-script.com
The
definitive Oracle Script collection for every Oracle professional DBA
|
|
