ORACLE AWR报告生成和分析
Automatic Workload Repository是10g引入的一个重要组件。在里面存贮着近期一段时间内，默认是7天，数据库活动状态的详细信息。
AWR报告是对AWR视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份AWR报告。
exec dbms_ate_snapshot;
... running the specified workload
exec dbms_ate_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采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括：
oracle 时间转换● background elapsed time
⏹ background cpu time
◆ RMAN cpu time (backup/restore)
● DB time
⏹ DB CPU
⏹ connection management call elapsed time
⏹ sequence load elapsed time
⏹ sql execute elapsed time
⏹ parse time elapsed
◆ hard parse elapsed time
● hard parse (sharing criteria) elapsed time
● hard parse (bind mismatch) elapsed time
◆ failed parse elapsed time
● failed parse (out of shared memory) elapsed time
⏹ PL/SQL execution elapsed time
⏹ inbound PL/SQL rpc elapsed time
⏹ PL/SQL compilation elapsed time
⏹ Java execution elapsed time
⏹ repeated bind elapsed time
我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。这两个值在AWR里面也有记录:
Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds，再除以总的 BUSY_TIME + IDLE_TIME：
% Total CPU = 1341.8/1941.76 = 69.1%，这刚好与上面Report的值相吻合。
其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。
用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。这里 5.3/8 = 66.25 %，比69.1%稍小，说明DB在后台也消耗了大约3%的CPU。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。