Oracle Read-Ahead: not the same as look-ahead, yes?

Question

Hi,
I've tried to understand the Oracle Read-Ahead systems, and I think I undersand how it works, though I'd like to assert that I am not mistaken.
From what I've managed to understand in the Oracle documentation, the Oracle read-ahead mechanism is mostly used for sequential accesses of data blocks. For example, to perform operations like table scans.
In such cases, Oracle will for example use a physical operation called scattered read.
The scattered read, in turn, is configured in the ini.ORA by a parameter name something like db_multiblock_read_count. Having a multiblock read count of 60, will make the scattered read operation read 60 sequential data blocks from disk, starting with the data block that was requested in the operation.
From what I've gathered, this is the basis of the Read-ahead mechanism. It is use mult block operations do read data instead of single bock operations.
If what I've said so far is correct. There are two things that I'd like to know:
1.
Those 60 blocks read by the sctarred read. Do they go directly into the database buffer cache? Or are they loaded first in to a lower level cache, like a scattered read cache?
Thus, if the table scan requested the page 1. And the scattered read operation fetched the database pages 1 to 60. I assume that only page 1 would be transfered to the buffer cache. Later on, when the table scan requested for page 2, the buffer cache would retrieve that page from the scattered read cache into the buffer cache. Or is this completly wrong? And when the scattered read gets pages 1 to 60. It automatically dumps those data pages into the buffer cache into random positions of the main buffer?
2.
With Oracle read-ahead, table scans and other such physical operations will always incur scattered read waits periodically. For example, every 60 pages the table scan incurs in another scattered read wait correct?
3.
Reading-ahead In oracle only anticipates the database page needs of a physical operator a specific point in time, yes? The following does not happen:
While the table scan is currently on page 50, having another 10 more pages left in the database buffer, some background process decides that it is a good idea request another fetch for 50 more data pages. In such a way that the forground thread processing the table scan never has stop in read IO.
This would be called looking-ahead, and it is not an Oracle feature, is it?
Thank you for your insight.
I've performed some tests where though the table size of a data transformations remain the same (1GB) but the time I take to process the source table into my output varies. The processing time for each record increased greatly from test to test. But I noticed that the wait time of the data transformation remained constant, though the cpu time increased greatly. THe increase in CPU time means that the Time Until Next Buffer fetch was reduced, which would give more time for the system to look-ahead. Eventally I could have made the CPU time so great, that if REad IO was being performed in anticipation it would be theortically possible for the READ wait time to be 0. Which I know is not going to happen. So I'd just to be certain of how the read-ahead works.
My best regards.

Answer 1

sono99 wrote:
Hi,
I've tried to understand the Oracle Read-Ahead systems, and I think I undersand how it works, though I'd like to assert that I am not mistaken.
From what I've managed to understand in the Oracle documentation, the Oracle read-ahead mechanism is mostly used for sequential accesses of data blocks. For example, to perform operations like table scans.
In such cases, Oracle will for example use a physical operation called scattered read.
The scattered read, in turn, is configured in the ini.ORA by a parameter name something like db_multiblock_read_count. Having a multiblock read count of 60, will make the scattered read operation read 60 sequential data blocks from disk, starting with the data block that was requested in the operation.
From what I've gathered, this is the basis of the Read-ahead mechanism. It is use mult block operations do read data instead of single bock operations.
Am not sure if you meant reading multiple blocks at the same time or Read ahead cache features provided by some storage devices. But to me it seems you are talking about MBRC (Multiblock read count) and not about read ahead cache provided by storage vendors.
If what I've said so far is correct. There are two things that I'd like to know:
1.
Those 60 blocks read by the sctarred read. Do they go directly into the database buffer cache? Or are they loaded first in to a lower level cache, like a scattered read cache?
Thus, if the table scan requested the page 1. And the scattered read operation fetched the database pages 1 to 60. I assume that only page 1 would be transfered to the buffer cache. Later on, when the table scan requested for page 2, the buffer cache would retrieve that page from the scattered read cache into the buffer cache. Or is this completly wrong? And when the scattered read gets pages 1 to 60. It automatically dumps those data pages into the buffer cache into random positions of the main buffer?
If my mbrc is 60, and none of the blocks are in buffer and table size is more than 60 blocks then entire 60 blocks would get transferred to buffer cache. There is nothing called scattered read cache in the architecture of Oracle.
2.
With Oracle read-ahead, table scans and other such physical operations will always incur scattered read waits periodically. For example, every 60 pages the table scan incurs in another scattered read wait correct?
Yes db file scattered read wait event would mean that another physical IO has been initiated for fetching next blocks of records.
3.
Reading-ahead In oracle only anticipates the database page needs of a physical operator a specific point in time, yes? The following does not happen:
While the table scan is currently on page 50, having another 10 more pages left in the database buffer, some background process decides that it is a good idea request another fetch for 50 more data pages. In such a way that the forground thread processing the table scan never has stop in read IO.
This would be called looking-ahead, and it is not an Oracle feature, is it?
Yes I do not think so it is an Oracle feature but some storage vendor provides it. It is also known as Read ahead.
Thank you for your insight.
I've performed some tests where though the table size of a data transformations remain the same (1GB) but the time I take to process the source table into my output varies. The processing time for each record increased greatly from test to test. But I noticed that the wait time of the data transformation remained constant, though the cpu time increased greatly. THe increase in CPU time means that the Time Until Next Buffer fetch was reduced, which would give more time for the system to look-ahead. Eventally I could have made the CPU time so great, that if REad IO was being performed in anticipation it would be theortically possible for the READ wait time to be 0. Which I know is not going to happen. So I'd just to be certain of how the read-ahead works.
My best regards.I did not understood your last para.
Regards
Anurag