如何分析AWR.docVIP

如何分析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报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是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 2) background cpu time 3) RMAN cpu time (backup/restore) 1) DB time 2) DB CPU 2) connection management call elapsed time 2) sequence load elapsed time 2) sql execute elapsed time 2) parse time elapsed 3) hard parse elapsed time 4) hard parse (sharing criteria) elapsed time 5) hard parse (bind mis