Statspack
首先查询安装所需的参数
确定job_queue_processes大于0并且timed_statistics为TRUE。
创建安装所需表空间
执行创建脚本
设定perfstat用户密码
选择perfstat用户工作表空间
选择临时表空间
出现如上图所示，证明创建完成。
检测是否有错误，如果有错误，可以执行@ ?/rdbms/admin/spdrop.sql脚本删除并重建
建立snap level为7的snapshot
执行一些脚本
再次执行一次快照
执行报告生成脚本
执行上图所示脚本可以自动设置job通过系统时间定时收集报告（默认为1个小时）
脚本中主要内容如上图所示，我们可以根据自己需求拷贝修改这个命令（这里不再详细演示）。
Statspack分析报告详解：
statspack 输出结果中必须查看的十项内容
1、负载间档（Load profile）
2、实例效率点击率（Instance efficiency hit ratios）
3、首要的5个等待事件（Top 5 wait events）
4、等待事件（Wait events）
5、闩锁等待
6、首要的SQL（Top sql）
7、实例活动（Instance activity）
8、文件I/O（File I/O）
9、内存分配（Memory allocation）
10、缓冲区等待（Buffer waits）
这个很多大牛都详细解释过，Oracle的官方文档也有详细解释，限于篇幅不再详解。
AWR报告
AWR（Automatic Workload Repository）报告是Oracle 10g之后推出的重要性能诊断工具。AWR是作为Statspack报告的一种有力延伸。借助AWR，我们可以方便的对Oracle数据库的特定工作时间段进行性能分析评价，最终达到发现瓶颈调优的目标。作为DBA，手工生成AWR报告是工作基本功之一。
首先创建AWR所需快照
产生awr report
默认为html格式
我们来统计7天的报告
确认初始与结束快照ID
如果中途数据库有关闭或重启操作，则会报上图所示错误，两个快照间的报告不能有断档（statspack也一样）。
确认报告名称
报告演示一览
产生addm report
确认初始与结束快照ID
确认报告名称
产生ash report
默认为html格式
确认周期与时间
确认报告名称
报告演示一览
产生对比报告
演示一览（这个报告一般是进行了性能调优以后才看的，像我这样没有实际意义）
在10gR2中，awr报表实际上是statpack报表的延伸，当然10gR2中还是保留了statpack，并且statpack也增加了对stream_pool的监控，awr与statpack的区别就是awr的快照的收集与维护更加自动化，默认的保留七天的快照，并且可以通过dbms_workload_repository表修改快照的收集频率与快照的保留时间，dba要干预的已经很少了，比statpack维护更简单。
awr与ash的最主要的区别在于：awr是平面的，全面的，ash是立体的，更侧重于session的event跟踪，由于业务量大的数据库的event wait是瞬息万变，awr很可能会监控不到，为了弥补这个不足，ash才可以对session的event进行跟踪。
ash与addm的区别在于：addm偶重于基于对当据库当前状态的分析，对存在的问题提供指导性的意见，可以说ash，addm是awr的补充，awr全面地收集数据库的状态，但ash/addm是侧重要对收集的数据进行分析，并提供一些有益的建议。
本文转自bear_cat51CTO博客，原文链接：http://blog.51cto.com/bearlovecat/844904 ，如需转载请自行联系原作者
