DB time可以用来判断数据库整体是否繁忙，如果Elapsed*CPU个数小于DB time，代表数据库整体比较繁忙，CPU负载会比较高.
Report Summary分为8个部分，最主要的是load Profile
主要显示数据库得一些整体性能总体参数，部分介绍如下：
redo size: 用来显示平均每秒得日志大小和平均每个事务得日志大小，有时候可以结合transactions每秒事务数，分析当前事务得繁忙程度
logical read:逻辑读耗CPU，逻辑读高则往往DB CPU也很高，也往往可以看到 latch:cache buffer chains 等待.
physical read:物理读，物理读耗IO
parses:解析次数，包含软解析+硬解析，理想状态是解析一次，到处运行
hard parses:硬解析，最好少于每秒20次
NOTE: load frofile提供了两个维度，per second 和 per transaction事务数， per second 主要是快照抓到的值除以两个快照之间的秒数，这是我们判断得主要维度，per transaction则是除以两个快照之间的事务数
这块整体的值越高越好，Parse CPU to Parse Elapsd %: 表示解析实际运行时间/(解析实际运行时间+解析中等待的资源时间)，越高越好，如果该比率为100%，意味CPU等待时间为0，没有任何等待.
Execute to Parse %:是该SQL执行和分析得比例，如果SQL重复利用率很高，则这个比率会很高，如果这个值太小，标识解析sql所消耗的cpu比较多，如果这个值越大，表示一次解析后被重复执行得次数越多
In-memory Sort %:在内存中排序的比率，如果这个值过低，说明有大量的排序在临时表空间，考虑调大SGA
Soft Parse %:软解析得百分比，softs/softs+hards,太低需要应用考虑使用绑定变量，小于95%，考虑使用绑定变量，小于80%，sql基本没有被重用
这里是排名前十的前台等待事件，
-
首先看wait class栏位，如果是 User I/O , System I/O, Others这种的可以不用太担心，如发现Concurrency这类等待需要特别关心
-
其次看等待时间，wait avg=total wait time(总等待时间)/waits(等待次数),最主要看平均等待时间是否正
操作系统层面，需要注意IO等待
上图为根据持续时间排序的SQL语句
所有栏位可根据字面上意思得出意义
- 如executions过多可能会引起CPU占用率高
- 如executions低，而elapsed time很高，则需要优化该SQL，降低执行时间
需要注意的是execution如果为0不代表未执行，代表在awr报告的持续范围内该语句未执行完成
https://www.cnblogs.com/fanpl/articles/8657703.html