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
看一下系统统计部分：
从这部分信息可以看出我们系统的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