Figure 2-9 is a report based on v$session_event. Notice the command-line parameter is the session identifier. The report was run twice with around a 30-second gap. If session 205 were active, we would expect some increased wait-event activity. Notice that a couple of the wait times did increase. We would never expect the wait time to decrease unless session 205 disconnected and then a new session 205 was initialized upon connection.

Figure 2-9. Based on the session level view, v$session_event, this report allows session-level wait time questions to be answered. Two snapshots are shown to demonstrate how as the session continues to be connected, its wait time can increase.

Session 205 in Figure 2-9 is primarily waiting for the operating system to complete multiblock IO requests. However, the operating system is doing a fantastic job, as the average time to retrieve multiple blocks is 1.12 ms. For self-preservation, I would not recommend confronting the IO subsystem team and implying their IO subsystem is not meeting expectations. In fact, as I'll discuss later, it very likely the operating system bottleneck is related to the CPU!