Figure 4-18. This response-time graph contrasts two configurations with the same device speed and same system arrival rate. The one difference is the dotted line has a queue for each device (like an IO subsystem) and the solid line has a single queue feeding all the devices (like a CPU subsystem). As the graph shows, when each device has its own queue, queuing immediately occurs, resulting in an immediate response time increase.

Based on Figure 4-18, IO subsystem vendors have a difficult problem. Their goal is to somehow, with all their caching and advanced algorithms, to transform the dotted-line situation into the solid-line situation. To transform one fundamentally different queuing system into another is expensive and very difficult. This is one reason IO subsystems seem so expensive.

Using Oracle's wait interface, it is extremely simple to detect an IO bottleneck. If you want to know how long it takes the IO subsystem to respond to a single or multiblock read request, or how long it takes the IO subsystem to complete a multiblock database writer or log writer request, you need not go any further than a simple wait event report. Of course, you can also use standard operating system reports like iostat and sar. You can even get a bit tricky and use operating system process tracing to remove Oracle from the equation. But I'm getting ahead of myself!