最详尽的AWR报告详细分析.docx

PAGE PAGE 10深圳博睿同创信息技术有限公司 AWR AWR 报告详细分析 AWR 是 Oracle 10g 版本 推出的新特性， 全称叫Automatic Workload Repository- 自动负载信息库, AWR 是通过对比两次快，照(snapshot)收集到的统计信息，来生成报表 数据，生成的报表包括多个部分。 WORKLOAD REPOSITORY report for DB Id Instance Inst num Release RAC Host ICCI 96 ICCI1 1 10.2.0. YES HPGICCI1 Snap Id Snap Time Sessions Cursors/Session Begin Snap: 2678 25-Dec-08 14:04:50 24 End Snap: Elapsed: DB Time: 2680 25-Dec-08 15:23:37 (mins) (mins) 26 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 耗时分钟，CPU 利用率只有大约 2%（79）。说明系统压力非常小。 列出下面这两个来做解释： Report A: Snap Id Snap Time Sessions Curs/Sess Begin Snap: 4610 24-Jul-08 22:00:54 68 End Snap: 4612 24-Jul-08 23:00:25 17 Elapsed: (mins) DB Time: (mins) Report B: Snap Id Snap Time Sessions Curs/Sess Begin Snap: 3098 13-Nov-07 21:00:37 39 End Snap: 3102 13-Nov-07 22:00:15 40 Elapsed: (mins) DB Time: (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 就共有 60*8=480 分钟，DB time 为分钟，则： cpu 花费了分钟在处理Oralce 非空闲等待和运算上(比方逻辑读) 也就是说cpu 有 480*100% 花费在处理Oracle 的操作上，这还不包括后台进程看 Report B，总共约 60 分钟，cpu 有 480*100% 花费在处理Oracle 的操作上很显然，2 中服务器的平均负载很低。 从 awr report 的 Elapsed time 和 DB Time 就能大概了解db 的负载。 可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。 Report Report Summary Cache Sizes Begin Begin End Buffer Cache: 3,344M 3,344M Std Block Size: 8K Shared Pool Size: 704M 704M Log Buffer: 14,352K 显示 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 的设置要确保最近使用