如何分析AWR分析和总结.pdf

如何分析 AWR Automatic Workload Repository 是 10g 引入的一个重要组 件。在里面存贮着近期一段时间内，默认是 7 天，数据库活 动状态的详细信息。 AWR 报告是对 AWR 视图进行查询而得到的一份自动生成的 报告。可以通过下面的脚本手工得到一份 AWR 报告。 exec dbms_workload_repository.create_snapshot; ... running the specified workload exec dbms_workload_repository.create_snapshot; @?/rdbms/admin/awrrpt 通过 AWR 和 AWR 报告， DBA 可以容易地获知最近数据库 的活动状态，数据库的各种性能指标的变化趋势曲线，最近 数据库可能存在的异常，分析数据库可能存在的性能瓶颈从 而对数据库进行优化。 AWR 报告所有的数据来源于 AWR 视图，即以 DBA_HIST_ 开头的所有系统表， Database Reference有对所有这些系统表 的描述，这应该是 Oracle 官方对 AWR 报告的官方注释了。 而对于如何有效地去分析 AWR 报告，这可能更需要 DBA 经 验的日积月累。 AWR 的前身是 Statspack，Statspack 在 10g 和 11g 中也有提 供，同时和 AWR 一起做了同步更新，而且 Statspack 是公开 源代码的，因此，关于 Statspack 的资料，还有 Statspack 的 源代码，都是理解 AWR 的一个有用的辅助。 本系列文章准备着重对 AWR 中的一些要点进行剖析，欢迎 一起讨论 AWR 相关的问题。 如果关注数据库的性能， 那么当拿到一份 AWR 报告的时候， 最想知道的第一件事情可能就是系统资源的利用情况了，而 首当其冲的，就是 CPU 。 而细分起来， CPU 可能指的是 OS 级的 User%, Sys%, Idle% DB 所占 OS CPU 资源的 Busy% DB CPU 又可以分为前台所消耗的 CPU 和后台所消耗的 CPU 如果数据库的版本是 11g，那么很幸运的， 这些信息在 AWR 报告中一目了然 : OS 级的 %User 为 75.4 ，%Sys 为 2.8 ，%Idle 为 21.2 ，所以 %Busy 应该是 78.8 。 DB 占了 OS CPU 资源的 69.1 ，%Busy CPU 则可以通过上面 的数据得到： %Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69 ，和报告的 87.7 相吻合。 如果是 10g 呢，则需要手工对 Report 里的一些数据进行计算 了。 Host CPU 的结果来源于 DBA_HIST_OSSTAT ，AWR 报告里 已经帮忙整出了这段时间内的绝对数据 (这里的时间单位是 centi second,也就是 1/100 秒) 这里， %User = USER_TIME/(BUSY_TIME+IDLE_TIME)*