Oracle's wait interface takes this timing information, gives the system call a special nonplatform-specific name, records the timing information, and makes this all available to us through its performance views. Regardless of the operating system or the actual system call, Oracle gives a multiblock IO call the special name db file scattered read, because these multiple blocks can be scattered over the IO subsystem. This Oracle-given name is more commonly called an event name, a wait event, or simply an event. From a performance analyst perspective, we tend to think of a multiple-block request as a sequential request, but looking at the IO call from a more kernel-centric perspective, it is more appropriate to name the request a scattered read.

Oracle associates the wait event name with the wait time, which in Figure 2-6 is 0.6 ms. If we had been looking at server process 14558 through Oracle's wait event interface during the time of the Figure 2-6 trace, we would have seen the server process was posting a db file scattered read. I like to say that the Oracle process is yelling out the wait event as it impatiently waits for the operating system to return the requested blocks. After the server process was done waiting, we would see that the time waited was 0.6 ms. So, in a very real way, Oracle has made this tracing information available to us without tracing, but through its wait interface. Beautiful simplicity!

Every Oracle process is either posting a wait event or consuming CPU3-there are no exceptions. This means that if you have hundreds of Oracle sessions, there is a good chance you'll have hundreds of sessions posting wait events. Knowing that sessions either consume CPU or post a wait event will become more important as you go deeper into performance analysis.