十二.性能测试-AWR报告简要分析

AWR 是 Oracle 10g 版本 推出的新特性， 全称叫 Automatic Workload Repository自动负载信息库 , AWR 是通过对比两次快照 (snapshot) 收集到的统计信息，来生成报表 数据，生成的报表包括多个部分。

一、Report Summary

DB Time 不包括 Oracle后台进程消耗的时间。 如果 DB Time 远远小于 Elapsed 时间，说明数据库比较空闲。 db time= cpu time + wait time（不包含空闲等待） （非后台进程） 说白了就是 db time 就是记录的服务器花在数据库运算 (非后台进程 )和等待(非空 闲等待 )上的时间 DB time = cpu time + all of nonidle wait event time 在 79 分钟里（其间收集了 3 次快照数据），数据库耗时 11 分钟， RDA 数据 中显示系统有 8 个逻辑 CPU（4 个物理 CPU），平均每个 CPU耗时 1.4 分钟， CPU 利用率只有大约 2%（1.4/79）。说明系统压力非常小。
列出下面这两个来做解释： Report A: Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1 End Snap: 4612 24-Jul-08 23:00:25 17 1.7 Elapsed: 59.51 (mins) DB Time: 466.37 (mins)
Report B: Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6 End Snap: 3102 13-Nov-07 22:00:15 40 16.4 Elapsed: 59.63 (mins) DB Time: 19.49 (mins) 服务器是 AIX 的系统， 4 个双核 cpu,共 8 个核: /sbin> bindprocessor -q The available processors are: 0 1 2 3 4 5 6 7 先说 Report A, 在 snapshot间隔中，总共约 60 分钟， cpu 就共有 608=480 分钟， DB time 为 466.37 分钟，则：
cpu 花费了 466.37 分钟在处理 Oralce 非空闲等待和运算上 (比方逻辑读 ) 也就是说 cpu 有 466.37/480100% 花费在处理 Oracle 的操作上，这还不包括后台进程 看 Report B，总共约 60 分钟， cpu 有 19.49/480*100% 花费在处理 Oracle 的操作上 很显然， 2 中服务器的平均负载很低。 从 awr report 的 Elapsed time 和 DB Time 就能大概了解 db 的负载。

可是对于批量系统， 数据库的工作负载总是集中在一段时间内。 如果快照周期 不在这一段时间内， 或者快照周期跨度太长而包含了大量的数据库空闲时间， 所 得出的分析结果是没有意义的。 这也说明选择分析时间段很关键， 要选择能够代 表性能问题的时间段。

二.Cache Sizes

显示 SGA 中每个区域的大小（在 AMM 改变它们之后），可用来与初始参数 值比较。 shared pool主要包括 library cache和 dictionary cache。library cache用来存储最 近解析（或编译）后 SQL、PL/SQL 和 Java classes等。library cache用来存储最 近引用的数据字典。发生在 library cache或 dictionary cache的 cache miss代价要 比发生在 buffer cache的代价高得多。因此 shared pool的设置要确保最近使用的 数据