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
Awr report 分析-IO stats
性能指标说明：
Reads: 发生了多少次物理读。
Av Reads/s : 每秒钟物理读的次数。
Av Rd(ms): 平均一次物理读的时间（毫秒），有一种说法是如果这个值大于7说明系统有严重的I/O问题，也有人说这个值不应该超过30，否则IO也可能有问题。硬件不同对IO瓶颈的判断也会相应的改变。
Av Blks/Rd:每次读多少个数据块。
Writes:发生了多少次写。
Av writes/s:每秒写的次数。
Buffer Waits:获取内存数据块等待的次数。
Av Buf Wt(ms):获取内存数据块平均等待时间。
V$FILESTAT
http://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_1107.htm#REFRN30087
IOPS (Input/Output Operations Per Second)，即每秒进行读写（I/O）操作的次数。
MBPS也就是带宽，每秒传输的比特（数据量），一个字节8比特(bit)。比如：4Mbps=每秒钟传输4M比特。
IOPS计算：
IOPS = Av Reads/s + Av Writes/s
MBPS计算：
MBPS=（Physical reads +Physical writes）* block_size =（0.12 + 0.28 ）*块大小
MBPS的的指标在 Load Profile 或 Instance ActivityStatistics 部分分别对应Physical reads 与Physical writes 或 physical writes 与 physicalreads。
相关描述说明：
Statistics Descriptions
http://docs.oracle.com/cd/B19306_01/server.102/b14237/stats002.htm#i375475
同样一个系统，我们可以设置一个基线作为依据，也可以判断出IO性能是否出现了问题，比如，在系统运行性能良好的时候做一个基线，当系统IO性能很差时，我们可以取一份report,然后对比两个report的性能指标，这样就可以准确诊断当前IO对性能的影响。
Awr report 分析-oracle 内存组件大小
在awr report中显示了oracle对各个内存组件大小的性能估算，包括Buffer Pool Advisory,PGA Memory Advisory,Shared Pool Advisory,SGATarget Advisory。
先看一下Report Summary里这方面的信息：
指标说明：
Memory Usage %：表示共享池内存使用率，应保持在75到90之间，如果太小说明分配的共享池过大，如果>90说明共享池中有争用，共享池内存不足。
% SQL with executions>1：执行次数大于1的SQL语句的比率，太小的话要结合Parse，看看是不是有硬编码现象，避免过多的sql硬解析。
% Memory for SQL w/exec>1：执行次数大于1的SQL语句所消耗的内存，占所有SQL语句消耗内存的比率。
指标说明：
Size for Est (M)：oracle 估算buffer pool的大小。
Size Factor：估算值与实际值的一个比例，比如0.9，代表估算值是实际值大小的90%，1.0代表buffer pool的实际大小。
Buffers for Estimate：估算的buffer pool的大小(数量)。
Est Phys Read Factor：估算的物理读的影响因子，是估算物理读和实际物理读的一个比例，1.0代表实际的物理读。
Estimated Physical Reads：估算的物理读的次数。
可以看出系统的实际bufferpool的大小是380M（Size Factor=1.0）。我们应该找到SizeFactor的改变对物理读影响最大的点，即Size Factor=0.66的点。从Size Factor=0.57的物理读次数391999降到Size Factor=0.66的物理读次数414222，以后物理读的变化很小，或基本没有变化。即buffer pool为252M时，效率是最高的。
指标说明：
PGA Target Est (MB)：估算PGA 的大小。
Size Factr：影响因子。
W/A MB Processed：oracle为了产生估算处理的数据量。
Estd Extra W/A MB Read/ Written to Disk：处理数据中需要物理读写的数据量。
Estd PGA Cache Hit %：估算的PAG命中率。
Estd PGA Overalloc Count：需要在估算的PGA大小下额外分配内存的次数。
这份数据没有任何代表性！这里需要掌握两个点：1）oracle估算的PGA大小不会导致额外分配内存的点。2）物理读写值（Estd Extra W/A MB Read/ Written to Disk）不再增加的点。不过还要考虑当前内存是否充足。
指标说明：
Shared Pool Size(M)：估算的共享池大小。
SP Size Factr：影响因子。
Est LC Size (M) ：估算的库高速缓存占用的大小。
Est LC Mem Obj：高速缓存中的对象数。
Est LC Time Saved (s) ：需要额外将对象读入共享池的时间。
Est LC Time Saved Factr：额外将对象读入共享池的时间影响因子。
Est LC Load Time (s) ：分析所花费的时间。
Est LC Load Time Factr：分析花费事件的影响因子。
Est LC Mem Obj Hits：内存中对象被发现的次数。
这里主要看Est LC Time Saved Factr这一列，它表示将对象读入共享池的影响情况，当这个值变化很小或不变的时候，增加shared pool的值就没有太大意义了。这样看来，这里应该将shared pool 设置为80M。共享池设置大了，这正好验证了Shared Pool Statistics中Memory Usage %列说明。
指标说明：
SGA Target Size (M)：估算的SGA大小。
SGA Size Factor：影响因子。
Est DB Time (s)：估算的SGA大小计算出的DB TIME。
Est Physical Reads：估算的物理读次数。
同样找到影响最大的点，即Size Factor=0.75的点。
Awr report 分析-其它
OLTP系统中必须关注的两个性能指标是LibraryHit与Buffer Hit。Library Hit指共享池中sql解析的命中率; Buffer Hit指内存数据块命中率。
关于这两项性能指标可以查看:
oracle SharedPool优化思路 http://www.linuxidc.com/Linux/2011-07/38912.htm
oracle Buffer Cache优化思路 http://www.linuxidc.com/Linux/2011-11/48052.htm
SQL ordered by Elapsed Time
image
这部分以sql消耗时间降序排列。
指标说明：
Elapsed Time (s):该条sql消耗的总时间。
CPU Time (s):该条sql花费的总cpu时间。
Executions:该条sql执行次数。
Elap per Exec (s):该条sql执行一次消耗的平均时间。
% Total DB Time:该条sql消耗总时间（ElapsedTime）占数据库时间(DB Time)的百分比。
SQL ordered by CPU Time
% Total DB Time is the Elapsed Time of theSQL statement divided into the Total Database Time multiplied by 100
这部分以sql消耗的cpu时间降序排列。
指标说明:略
SQL ordered by Gets
image
这部分以sql获取内存数据块的数量降序排列。
指标说明:
Buffer Gets：sql获取内存数据块总数量。
Executions：sql执行次数。
Gets per Exec：sql执行一次获取内存数据块数量。
%Total：占内存数据块的百分比。
CPU Time (s) ：sql花费的总cpu时间。
Elapsed Time (s)：sql消耗的总时间。
SQL ordered by Reads
这部分以sql物理读降序排列。
SQL ordered by Executions
这部分列出sql执行次数信息。
指标说明：
Rows Processed：sql处理的总记录数。
Rows per Exec CPU per Exec (s)：sql每次执行处理的记录数。
OLTP可以关注，OLAP无须关注（因为sql重复执行的频率很低）。
SQL ordered by Parse Calls
这部分列出sql被分析次数（不区分硬分析与软分析）的信息。
指标说明：
Parse Calls：sql分析的次数。
% Total Parses：占总分析次数的百分比。
SQL ordered by Sharable Memory
这部分列出sql占用library cache大小的信息。
指标说明：
Sharable Mem (b)：占用librarycache的大小。
SQL ordered by Version Count
这部分列出sql版本数信息。
指标说明：
Version Count：sql版本数。
OLTP可以关注。
SQL ordered by Cluster Wait Time
这部分列出集群等待时间信息。
指标说明：
Cluster Wait Time(s):集群等待时长。
CWT% of Elapsd Time:集群操作等待时长占总时长（ElapsdTime(s)）的百分比。
