*Oracle7.3 and onward(This behavior may have started in an earlier version of Oracle) generates multi-block db file sequential read events when a dedicated server process reads temporary segment data from disk (The wait-events-are-named-backwards hypothesis starts to crack when you see your first multiblock db file sequential read). Older releases of Oracle would read temporary segment data into the database buffer cache using db file scattered reads. Newer releases exploit the heuristic that temporary segment data isn’t likely to be sharable or revisited, so it reads directly into a server process’ program global area (PGA).

A db file scattered read event occurs when the memory receiving the contents of a disk read is not guaranteed to be contiguous. The Oracle kernel could have been designed to spend more time finding a group of contiguous free buffers that could be filled with a read(). Doing it this way would have provided a net benefit only if the additional time consumed were offset by a sufficient speed advantage of read() over readv(). The cost of searching for contiguous buffers probably overwhelmed any advantage read() might have over readv(), motivating Oracle’s kernel developers to choose the algorithm they did.

* In most circumstances, full-table scans and fast full-index scans generate one or more db file scattered reads. However, there are times when these scans generate only db file sequential read events.