CPU time events
CPU变为top wait event并不总是代表出现了问题。但是如果同时数据库性能比较慢，那么就需要进一步分析了。首先，检查AWR报告的“ SQL ordered by CPU Time ”部分，看是否某个特定的SQL使用了大量的CPU。
SQL ordered by CPU Time
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> % Total is the CPU Time divided into the Total CPU Time times 100
-> Total CPU Time (s): 56,207
-> Captured SQL account for 114.6% of Total
CPU Elapsed CPU per % Total
Time (s) Time (s) Executions Exec (s) % Total DB Time SQL Id
---------- ---------- ------------ ----------- ------- ------- -------------
20,349 24,884 168 121.12 36.2 9.1 7bbhgqykv3cm9
Module: DBMS_SCHEDULER
DECLARE job BINARY_INTEGER := :job; next_date TIMESTAMP WITH TIME ZONE := :myda
te; broken BOOLEAN := FALSE; job_name VARCHAR2(30) := :job_name; job_subname
VARCHAR2(30) := :job_subname; job_owner VARCHAR2(30) := :job_owner; job_start
TIMESTAMP WITH TIME ZONE := :job_start; job_scheduled_start TIMESTAMP WITH TIME
Analysis:
• -> Total CPU Time (s): 56,207
它代表了15分钟的CPU time。但是这个数字是否有问题取决于整个报告的时间。
• Top SQL使用的CPU是 20,349秒（大概5分钟）
• 整个CPU时间占DB Time的9.1%
• 执行了168次，这个执行次数跟之前提到的几个SQL是一样的，说明这些SQL可能都是被同一个JOB调用的。
其他潜在的CPU相关的问题：
• 检查是否有其他等待事件与高CPU 事件同时出现 如cursor: pin S问题可能引起高CPU使用：
• 数据库以外的CPU使用率过高 如果一个数据库以外的进程使用了过多CPU，那么数据库进程能够获得的CPU就会减少，数据库性能就会受到影响。在这种情况下，运行OSWather或者其他的OS工具去发现是哪个进程使用了过多CPU
• 诊断CPU使用率 可以参考我已经写的《从操作系统命令TOP到数据库的优化》文章。
•
'Log file sync' waits
当 一个user session commit或rollback时，log writer进程会把redo从log buffer中写入redo logfile文件。AWR报告会帮助我们来确定是否存在这方面的问题，并且确认是否是由物理IO引起。
•
Buffer busy waits
当 一个session从buffer cache读取一个buffer时，如果这个buffer处于busy的状态（由于其它session正在向其中读取数据，或者是由于这个buffer被 其它的session以不兼容模式持有），那么这个session就会等待这个事件。
使用ADDM的报告
当分析性能问题时，除了AWR报告，我们还可以同时参照ADDM报告，对于潜在的性能问题，它同时提供了具体的解决方案建议。
ADDM报告相比AWR报告来说，它提供了可读性更好的建议；当然应该同时参照ADDM报告和AWR报告来得到更准确地诊断。
Statspack
AWR报告取代了旧有的staspack及bstat/estat报告。