The report in Figure 4-22 show there are three devices that are not able to respond fast enough: sdc, sdd, and sdg. Device sdc is experiencing heavy read activity, has a response time of 23 ms, and is 74% busy. Device sdd is also experiencing heavy read activity, has a response time of 14 ms, and is 66% busy. I would expect the top few wait events to be related to IO reads. It is very satisfying to see Oracle is experiencing long read request response times based on both the wait interface and also iostat. Device sdg is experiencing heavy write activity, has an 18 ms response time, and is 81% busy. The writes could be caused from either the log writer or the database writer. We cannot tell which from this operating system-focused analysis. However, when we combine the operating system analysis with the ORTAs, we should be able to see if the issue is focused on the database writer, log writer, or both.

Whenever I encounter an IO issue, I always frame it in terms of Oracle and application requirements, and IO subsystem capacity. This not only implies there are three areas to focus on for solutions, but it immediately disarms everyone involved (that is, unless they really messed up and performed what I call a career decision).

I have seen the IO subsystem misconfigured. Vendors won't admit this as a possibility until cornered with both Oracle and operating system tracing proof. Usually, the problem is a physical connection issue, where too much IO activity is going through too few connections. A relatively simple reconfiguration can actually solve the problem.