You still need to access the buffer, so you can't simply give up. While the buffer is not in memory, it is in a database file on disk (otherwise the data dictionary would not have showed this block was of interest to you). So you must make a system call to the IO subsystem requesting your single block. Just before you make the IO request, you ask the operating system for the time by issuing the gettimeofday system call. While you are waiting for the operating system to return the block, you are yelling, "db file sequential read!"

When you finally get the block from disk, you again issue a gettimeofday call, calculate the time difference, and record that into Oracle's wait interface structures for anyone to see via wait event views. Now with the block in hand, you still cannot peek inside, as it must first be appropriately placed in the buffer cache and all the relevant memory structures must be appropriately changed. How this is performed is what much of the rest of this chapter is about.

One of the best (and most interesting) ways to learn how to solve performance problems is to devise ways to create the problem! Referring to Figure 6-9, there are three classic ways to slow CBC performance: