文档介绍：详细分析 ORACLE AWR 报告 AWR 是 Oracle 10g 版本推出的新特性, 全称叫 Automatic Workload Repository- 自动负载信息库, AWR 是通过对比两次快,照(snapshot) 收集到的统计信息,来生成报表数据,生成的报表包括多个部分。 WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst num Release RAC Host ICCI 1314098396 ICCI1 1 YES I1 Snap Id Snap Time Sessions Cursors/Session Begin Snap: 2678 25-Dec-08 14:04:50 24 End Snap: 2680 25-Dec-08 15:23:37 26 Elapsed: (mins) DB Time: (mins) DB Time 不包括 Oracle 后台进程消耗的时间。如果 DB Time 远远小于 Elapse d 时间,说明数据库比较空闲。 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% ( )。说明系统压力非常小。列出下面这两个来做解释: 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: 01234567 先说 Report A,在 snapshot 间隔中,总共约 60 分钟, cpu 就共有 60*8=480 分钟, DB tim e 为分钟,则: cpu 花费了分钟在处理 Oralce 非空闲等待和运算上( 比方逻辑读) 也就是说 cpu 有 *100% 花费在处理 Oracle 的操作上,这还不包括后台进程看 Report B ,总共约 60 分钟, cpu 有 *100% 花费在处理 Oracle 的操作上很显然, 2 中服务器的平均负载很低。从 awr report 的 Elapsed time 和 DB Time 就能大概了解 db 的负载。可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。 Report Summary Cache Sizes 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 。 li