Figure 9-18. Shown is the response-time effect of increasing capacity by adding transaction processors (for example, CPU cores). By adding CPU cores, a new response-time curve takes effect (dotted line). The response time drops from point A to point B. By controlling the workload, performance can remain at point B, or by allowing the workload to increase to point C, the system can still maintain both improved response time and an increased workload.

Workload management can provide arguably the most elegant of all performance improvements. And of all the missed performance-improving opportunities, I would say better workload management has got to be near the top. While shifting workloads may not be a very satisfying technical challenge (though it can be), when the workload is better managed, peak workload and painful performance periods can be dramatically improved. And all this can occur without tuning Oracle, the application, or the operating system, and without any capital investment.

Suppose around time 13 in Figure 9-19 is when users are extremely upset. It's not time 23, because the users are asleep and the batch jobs are running just fine. The performance analyst must determine what is occurring-that is, the workload mix-during time 13 and work with the user community to shift a segment of that workload, perhaps to time 15. While this may seem unlikely, when confronted with a severe performance problem, a graphic clearly showing the situation (for example, Figure 9-19), users can be surprisingly flexible. But if they are told to change the way they work without understanding why, they will most likely rebuff any attempt to alter the workload.