The performance management trick is to ensure the requirements will fit into the available capacity. In fact, if we can mathematically express the requirements and capacity-injecting alterations such of politics, budget, purchases, timing, and new and changing workloads-we have a much better chance of anticipating change. But if we guess at the requirements or the capacity, then everyone is just plain lucky if the solution works.

Requirements are one of the two metrics we need to derive utilization. Requirements can take on many useful forms, like CPU seconds consumed per second or consumed in a peak workload hour, IO operations performed per hour or in a single hour, or megabytes transferred per second or per hour. We can also change the tense from the past, "CPU seconds used yesterday between 9 a.m. and 10 a.m." to "How much CPU is the application now consuming each second?" or to the future, "How much CPU time do we expect the application to consume during next year's seasonal peak?" Don't tie yourself to a single rigid requirement definition. Throughout your work, allowing a flexible requirements definition will help bring clarity to an otherwise muddy situation.

Requirements can also be articulated in terms of more traditional Oracle workload metrics like user calls, SQL statement executions, transactions, redo bytes, and logical IO. For example, referring to the workload profile shown in Figure 9-1, which is based on v$sysstat, the workload can be expressed as 415 uc/s, 0.22 trx/s, 145,325 LIO/s, or 22,926 redo bytes generated per second. Referring to Figure 9-2, the system requirements can also be expressed as 1,675,794 centiseconds (16,757.94 seconds) of CPU consumed over the 149.97-minute interval. This means on average every second, the Oracle instance consumed 1.862 seconds of CPU, which is a simpler way of saying 1.862 CPU seconds consumed per second. At first, it may seem strange to speak of CPU consumed like this, but it is very correct and sets us up for the next topic, which is capacity.