概述
关于如何获取awr以及两个时间段的awr比对报告请参考如下博文
Oracle-awrddrpt.sql比较两个AWR差异报告
AWR
手动执行一个快照：
Exec dbms_workload_repository.create_snapshot;- 1
创建一个AWR 基线
Exec
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id,end_snap_id ,baseline_name);
- 1
- 2
- 3
数据从哪里来，放哪里去
参数设置
请访问
Oracle-AWR管理包
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
对应进程
若是mmon若hang则意味着AWR不可用
AWR主要是MMON(Manageability Monitor Process)和它的小工进程(m00x)
MMON的功能包括:
1.启动slave进程m00x去做AWR快照
2.当某个度量阀值被超过时发出alert告警
3.为最近改变过的SQL对象捕获指标信息
其他脚本
使用@?/rdbms/admin/awrddrpt可以生成AWR比对报告
使用@?/rdbms/admin/awrgrpt可以生成RAC 全局AWR报告
使用@?/rdbms/admin/ashrpt.sql可以生成ASH报告
单实例下使用@/rdbms/admin/addmrpt.sql可以生成addm自诊断报告
RAC环境下生成指定实例的addm报告使用addmrpti.sql脚本
Oracle10g中推出了新的优化诊断工具：数据库自动诊断监视工具（Automatic Database Diagnostic Monitor :ADDM）和SQL优化建议工具（SQL Tuning Advisor: STA）。这两个工具的结合使用，能使DBA节省大量优化时间，也大大减少了系统宕机的危险。简单点说，ADDM就是收集相关的统计数据到自动工作量知识库(Automatic Workload Repository :AWR)中，而STA则根据这些数据，给出优化建议。
报告解读
我们获取了2018-03-30 0点到01点的AWR报告。我们来逐段分析下
数据库基本信息
第一行展示了数据库本身相关的信息：DB Name, DB Id , Instance Name, 数据库启动时间，以及版本和是否为RAC模式，没什么可多说的，很直观
第二行展示了数据库主机相关的信息：HostName，操作系统、CPU数量、内核数量、CPU Sockets和内存
http://kodango.com/cpu-topology
如果你只知道CPU这么一个概念，那么是无法理解CPU的拓扑的。事实上，在NUMA架构下，CPU的概念从大到小依次是：Node、Socket、Core、Processor。
随着多核技术的发展，我们将多个CPU封装在一起，这个封装一般被称为Socket（插槽的意思，也有人称之为Packet，不知到哪个更加准确？），而Socket中的每个核心被称为Core。为了进一步提升CPU的处理能力，Intel又引入了HT（Hyper-Threading，超线程)的技术，一个Core打开HT之后，在OS看来就是两个核，当然这个核是逻辑上的概念，所以也被称为Logical Processor，本文简称为Processor。
综上所述，一个NUMA Node可以有一个或者多个Socket，一个多核Socket显然包含多个Core，一个Core如果打开HT则变成两个Logical Processor。Logical processor只是OS内部看到的，实际上两个Processor还是位于同一个Core上，所以频繁的调度仍可能导致资源竞争，影响性能。
该图引用至http://fishcried.com/2015-01-09/cpu_topology/
第三行展示了快照时间内的数据库统计信息，很重要
包括Sessions 总数 ，Cursors/Session:平均每个session打开了多少cursor
Elapsed 逝去时间、DBTime,超级重要的指标
Elapsed 快照逝去时间，如果为了诊断特定时段性能问题则不宜过长，一般15 分钟~2 、3 个小时。如果是看全天负载那么可以长一些。较为常见是60分钟或者120分钟，根据实际需求，无标准。
Cursors/session ： open_cursors 如果设置的不合理会引起ORA-01000: maximum open cursors exceeded问题