合 如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)
理论实践：循序渐进理解AWR细致入微分析性能报告
本篇文章重点对 AWR 报告中的 DB Time、DBCPU、IO 等数据进行了说明，可帮助读者更加清楚的理解这些数据代表的含义，与数据库的性能表现有何关系。同时通过两个简短的例子，实践如何分析 AWR 报告。
\1. AWR 概述
Automatic Workload Repository(AWR) 是10g引入的一个重要组件。在里面存贮着近期一段时间内（默认是7天）数据库活动状态的详细信息。
AWR 报告是对 AWR 视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份 AWR 报告。
通过 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相关的问题。
\2. DB CPU - CPU负载分析
如果关注数据库的性能，那么当拿到一份 AWR 报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是 CPU。
而细分起来，CPU 可能指的是：
OS 级的 User%，Sys%， Idle%
DB 所占 OS CPU 资源的 Busy%
DBCPU 又可以分为前台所消耗的 CPU 和后台所消耗的 CPU
如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然：
分析上面的图片，我们可以得出下面的结论：
OS 级的 User%，Sys%，Idle%：
OS 级的 %User 为75.4，%Sys 为2.8，%Idle 为21.2，所以 %Busy 应该是 100-21.1=78.8。
DB所占OSCPU资源的Busy%
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秒)
根据上面的数据，稍加计算分析便可得出下面的结果。
OS级的User%，Sys%，Idle%：
%User = USER_TIME/ (BUSY_TIME+IDLE_TIME)100 =146355/ (152946+41230)100 = 75.37
%Sys = SYS_TIME/ (BUSY_TIME+IDLE_TIME)100=5462/(152946+41230)100=2.81
%Idle = IDLE_TIME/ (BUSY_TIME+IDLE_TIME)100=21230/(152946+41230)100=10.93
值得注意的，这里已经隐含着这个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
