There is much to say about this topic. I think it's worth mentioning
two additional related issues:
- while the RDBMS requests to the OS kernel to read db_block_size
times
db_file_multiblock_read_count from some file/device at some offset,
the kernel can split this one I/O into multiples, depending on
file system settings etc. On a lower level (logical volumes) these
read calls can be split again, spreading over multiple devices.
At a physical level, I/O's can be split up inside the I/O
subsystem.
E.g. inside an EMC box, the I/O size is always 32 kbyte.
Bottom line: changing db_file_multiblock_read_count should always
be considered with the I/O confuration in mind.
- When performing a full table scan, needed blocks in the buffer
cache can cause splits in the reading.
For instance, if the RDBMS needs blocks 11 to 20, each of the block
in the range is checked whether it exists in the buffer cache.
If block 15 is cached (the only one in the range), there will
be 2 reads: one for block 11 till 14, and one read for 16 - 20.
Kind Regards,
Herman de Boer
sr. consultant
IT Consultancy Group bv
Received on Thu Jan 10 2002 - 02:49:37 CST
