Oracle 10g 提供了一个新的性能采集和分析工具awr(automaticworkload repository)。

Awr存在于sysaux表空间，是sysaux的主要占用者之一。

快照，在特定时间捕获的一组性能统计信息，用于计算统计信息的更改率。每个快照由snap_id进行标识。

默认快照每60分钟生成一次。保留7天。

Awr快照集，一种用于标记和保留重要时段快照集数据的机制。一个快照集定义一对快照（两个快照）。快照集用于保留快照数据。在删除快照集之前，属于快照集的快照会一直存在。

一般情况下，可以将具有代表性的时段设置为快照集，以便用于与当前系统行为进行比较。

Awr compare periods 用于比较awr中两个时段。Awr显示两个快照（两个时间点）之间的awr数据，而awr compare periods 显示两个时段即两个awr report（相当于四个快照）之间的差异。根据两个时段之间报告的更改，可准确诊断性能降低的原因。

生成awr report,可运行$ORACLE_HOME/rdbms/admin/awrrpt.sql。

Awr快照设置,使用dbms_workload_repository.modify_snapshot_settings()。

生成awr快照集，可使用dbms_workload_repository.create_baseline ()。

生成awr compare periods,可运行$ORACLE_HOME/rdbms/admin/awrddrpt.sql。

Awr report 分析-CPU繁忙程度与CPU使用率

Sessons：采集时实例连接的会话数。

Cursors/Session：每个会话平均打开的游标数。

Elapsed:采样时间。

DB Time：代表了实例的工作负载，在时间模型统计中非常重要。

DB Time表示用户操作花费的时间，包括cpu时间（非后台进程花费时间(比如PMON)）和等待时间（非空闲等待时间）。

如果DB Time接近于Elapsed Time*cpu数，表明数据库比较忙，cpu负载也许比较大。这时很有可能是因为资源争用导致等待事件的结果，可以去top 5等待事件分析原因。

可以在Time Model Statistics部分获取DB Time的值与DB CPU的值。DB CPU 指用户操作的总的CPU时间，同样不包括后台进程花费的CPU时间（比如PMON）。那么DB Time去除掉DB CPU是不是就应该是等待时间？应该是，于是公式DB Time=DB CPU + 等待时间。

V$SESS_TIME_MODEL

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2087.htm#REFRN30340

看一下系统统计部分：

从这部分信息可以看出我们系统的CPU情况与内存等信息。

SYS_TIME与USER_TIME之和 1776 +4834 = 6610 正好等于BUSY_TIME，再者(6610 + 719387)/100/60/2 = 60.49975 ，这不是我们的采样时间吗？2代表两个cpu(NUM_CPUS)。上面提到DB CPU不包括后台进程花费的时间（比如PMON），而在Time Model Statistics中显示出了后台进程CPU时间(backgroundcpu time)。所以数据库的整体 cpu 使用情况可以这样计算吧,cpu使用率 = ( DB CPU + background cpu time ) / (Elapsed *NUM_CPUS) * 100% = ( 19.45 + 7.08 ) / ( 60.45mins * 2 )* 100% = 0.00366 %  。看来我们的系统很闲呀，我应该在系统稍微忙点的时候取一份report来分析。

V$OSSTAT

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2010.htm#REFRN30321

您可能感兴趣的文章: