| NUM_LCPUS | Probably 0 because LPARs not set up |
| NUM_VCPUS | Same thing |
| AVG_BUSY_TIME | BUSY_TIME/NUM_CPUS |
| AVG_IDLE_TIME | IDLE_TIME/NUM_CPUS |
| AVG_IOWAIT_TIME | IOWAIT_TIME/NUM_CPUS |
| AVG_SYS_TIME | SYS_TIME/NUM_CPUS |
| AVG_USER_TIME | USER_TIME/NUM_CPUS |
| BUSY_TIME | Time equiv of %usr+%sys in sar output |
| IDLE_TIME | Time equiv of %idle in sar |
| IOWAIT_TIME | Time equiv of %wio in sar |
| SYS_TIME | Time equiv of %sys in sar |
| USER_TIME | Time equiv of %usr in sar |
LOAD |
|
OS_CPU_WAIT_TIME |
Supposedly time waiting on run queues |
RSRC_MGR_CPU_WAIT_TIME |
Time waited coz of resource manager |
PHYSICAL_MEMORY_BYTES |
Total memory in use supposedly |
NUM_CPUS |
Number of CPUs reported by OS |
NUM_CPU_CORES |
Number of CPU sockets on motherboard |
If you want to convert the times (expressed in seconds) back into percentages, then total elapsed time is
e = BUSY_TIME + IDLE_TIME + IOWAIT TIME or
e = SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME since BUSY_TIME = (SYS_TIME+USER_TIME)
e should also be roughly close to elapsed time of report (59.78 min * 60 seconds/min * 8 (NUM_CPUS))
but the report itself takes time to run (actually the snapshots take time as well) and neither the snapshot,
the V$ tables the snapshot is taken from, nor the report itself are AS OF a single consistent point in time.
Anyway at this point you can see, (BUSY_TIME / e) = %busy.
Finally,
CPU used by this session 234,148 65.3 112.4
This is CPU time Oracle reports it used (though we don’t include time spent in SQL*Net code and maybe not all background
processes may be reporting the CPU time they used). It is expressed in centiseconds rather than seconds so
234,148 / (e * 100) will tell you what percent of the total CPU resources on the machine Oracle was keeping busy.
Actually it’s probably easier to look at DB CPU stat since that is already in seconds.
BUSY_TIME – “DB CPU” is the amount of CPU usage that seems to be because of things mostly happening outside the database.
最新评论