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

如何分析 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)*100 = 146355/(152946+41230)*100 = 75.37 %Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100 %Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100 值得注意的，这里已经隐含着这个 AWR 报告所捕捉的两个snapshot 之间的时间长短了。有下面的公式 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT 正确的理解这个公式可以对系统 CPU 资源的使用及其度量 的方式有更深一步的理解。 因此 ELAPSED_TIME = (152946+41230)/8/100 = 242.72 seconds 当然，这正确无误。 至于 DB 对 CPU 的利用情况，这就涉及到 10g 新引入的一个关于时间统计的视图了， v$sys_time_model，简单而言， Oracle 采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括:1) background elapsed time background cpu time RMAN cpu time (backup/restore) DB time DB CPU 2) connection management call elapsed time 2) sequence load elapsed time 2) sql execute elapsed time parse time elapsed hard parse elapsed time hard parse (sharing crite