重点关注
一 Snapshot Information
session 连接的总的会话数
Cursors/session 每个会话平均打开的游标数
Elapsed 快照产生的总时间 通过Elapsed/DB Time比较，反映出数据库的繁忙程度。如果AWR报告顶部的DB time远大于Elapsed Time，说明负载较高,记住 是远远大于
db_time
0 定义 数据库请求总的花费时间 举个例子就是一堆人从进理发店到出理发店 这段时间的总请求,包括在理发店里排队 DB等待 理发师为其理发(DB CPU) 时间 逻辑核心数就是理发师的数量 总时间/逻辑核心数 就是平均每个理发师所花费的总时间
1 计算公式
DB Time(请求时间)= DB Wait Time（DB等待时间）+ DB CPU Time（DB CPU服务时间） 不包括后台进程上CPU开销的时间以及前台进程非空闲等待时间
二 Load Profile
DB_TIME 为每秒DB所耗费的时间
DB_CPU 为每秒cpu所耗费的时间
Executes 为每秒的执行次数
Transactions 为每秒的事务数
Redo size 每秒产生的redo大小
hard parses 每秒产生的硬解析数量 不能超过100
parses 每秒产生的软解析数量 不能超过300
三 Foreground Events
1 等待的事件 2 等待的次数 3 等待的总时间(秒) 4平均等待时间(毫秒) 5 占据总DB_TIME时间的百分比 6 事件所属的类
等待事件 解析
dbfile sequential read 单个数据库
1 db file sequential read 是个非常常见的 I/O 相关的等待事件， 通常显示与单个数据块相关的读取操作， 在大多数的情况下， 读取一个索引块或者通过索引读取一个数据块时，都会记录这个等待。
2 如果这个等待事件比较显著 TOP 10内 ，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表;或者可能说明不加选择地进行索引 这个事件出现 不一定是坏事, 不能说明是性能问题
db file scattered read 多个数据块
四 main_report-sql statistics
这个会跳转到一个详细的SQL语句分析界面,各种维度的排行TOP SQL 进行观察
Reads 逻辑读 Physical Reads 物理读 Parse Calls 软解析调用 sharable Momory 共享池 cache CPU Time cpu耗时 Gets 总行数排行
请关注平均执行时间长的SQL语句
五 Instance Efficiency Percentages (Target 100%)
Buffer Hit % 数据缓冲命中率，表示了数据块在数据缓冲区中的命中率。
Buffer Hit<95%，可能是要加db_cache_size，但是大量的非选择的索引也会造成该值很高(大量的db file sequential read)。
Library Hit % 共享池中SQL解析的命中率。Library Hit<95%，要考虑加大共享池，绑定变量，修改cursor_sharing等。
Soft Parse %软解析占总解析数的百分比。可以近似当作sql在共享区的命中率。
Latch Hit % latch的命中率 其值低是因为shared_pool_size过大或没有使用绑定变量导致硬解析过多。要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。soracle