Since the move to all flash storage solutions, about ten years ago, CPU utilization and bottlenecks have frequently become the primary cause of performance concerns for Oracle DBAs. Whereas in the past the top wait events seen in a Statspack or AWR report might be “db file scattered read” or “db file sequential read”, our contemporary DBA is far more likely to see “CPU” atop the list.
It is important to remember that seeing “CPU” atop the wait events in an AWR report might indicate that the host CPUs are saturated, or it might indicate that there are single threaded processes within the database that are waiting on a single core to complete a compute operation.
And there is a trade off between more cores and clock speed. Generally speaking, within each generation of CPU, more cores means a slower clock. A denser processor with more cores will be able to handle a larger number of simultaneous compute operations – ideal of parallel query processing, analytics, AI and consolidation, whereas a lower core count with a higher clock speed is generally better suited for transaction processing applications, as well as being dramatically less expensive to license for the Oracle software.
Keeping an eye on host utilization then is an important part of an operational DBAs task list, and there are many excellent tools to do this across a large enterprise. In this post we explore a simple method to monitor host utilization from within the database, meaning that our DBA can use SQL*Plus access via TNS to databases to keep track of the underlying hosts.
the gruffdba 