AWR报告生成
@?/rdbms/admin/awrrpt.sql
指标1：DB TIME
eelapsed*CPUS>DB TIME 则系统压力不大，反之，则系统处于繁忙状态，很有可能有瓶颈。
上图是另一个系统的情况，269.76*12=3237.12>1539.18，但是可以看出，该系统比上面那个系统负载更高，换一种可以对比的计算方式，则是DB TIME/ELAPSED*CPUS*100%
则第一个系统负载为：26.3%
则第二个系统负载为：47.5%
说明第二个系统比第一个系统繁忙2倍左右
指标2：load profile 的 redo size和transaction
下面这个图的transaction为164.4个/s，redo size 为253197.2byte/s(247.3K/S)
说明该系统每秒提交的事物较少，产生的REDO日志较少
下面这个图可以看到，每秒事物数才8.4个，redo size 则为88KB/S，
说明该系统每秒提交的事物更加少，产生的REDO日志也更加少，那为何下面这个系统的负载是上面系统的2倍？这就要继续往下看
指标3 efficiency percentage
它是一些命中率指标
buffer hit 、library hit 都是SGA的命中率，
soft parse就是软解析的比例，
同时可以看到load profile里面的parses和hard parses，解析了385.1个SQL每秒，同时没有硬解析
说明该系统没有硬解析，说明该系统绑定变量状态很好
再对比下面这个
上面这个系统其实也都还好
指标4 TOP 10 foreground event by total wait time
主要关注EVENT 和%DB TIME 两列
可以看出，上图最多的等待事件时log file sync 占用了61.3%的DB TIME
而下图可以看到，DB CPU竟然占到了DB TIME 的92.8%，说明CPU异常繁忙，同时与操作系统中的TOP命令看到的结果相验证，CPU利用率太高，说明该系统要么需要更换硬件，要么有优化的空间，优化的目标就是降低CPU 使用率。
指标5 SQL statistics
直接分析执行时间最长的那些SQL即可
指标6 segment statistics
可以更加清晰地看到是哪些段需要优化
