Based on the Oracle analysis, you can anticipate what you will find in the application and the operating system analyses. In this situation, you would expect the operating system to be experiencing a raging CPU bottleneck and the application SQL to be asking for a lot of buffers (that is, buffer gets as opposed to block gets). Also, you will want to check the order-entry SQL. It's likely that the order-entry SQL is either causing the intense logical IO activity, and hence CBC activity, or being negatively affected by it.

A quick operating system analysis clearly shows a raging CPU bottleneck. As expected, the CPU subsystem is 90% busy on average, with a run queue nearly always greater than the number of CPU cores (which means processes are needing to wait for CPU resources). While the IO subsystem is doing some real work, there are no volumes busier than 60%, and their response times are well under the rule of thumb of 10 ms. There is no memory swapping. As in many cases, the network has been deemed out of scope. A solution focused on the operating system is to acquire more CPU cycles for Oracle processes. There are many ways to go about doing this, such as by identifying processes that do not need to be or should not be running during peak times.

For the application analysis, referencing a top SQL report, you look for SQL consuming the most buffers (buffer gets, or what I call logical IO). You quickly identify three statements that are consuming around 90% of all the logical IO. As expected, the top two statements are part of the order-entry application. An application-focused solution is to tune the SQL with the objective of reducing logical IO. It's fine to also reduce the physical IO, but the Oracle response-time analysis and the operating system analysis clearly support first and foremost focusing on logical IO-that is, buffer gets.