Oracle 报告的获取
Oracle 报告的获取
数据库问题排查的两种常用工具室获取执行计划及数据库性能报告.
对于 SQL 调优，和局部 SQL 问题，我们可以直接使用执行计划直接调优，而对于整个系统, 这时候就可以用 Oracle 系统自带的报告对系统进行整体分析了，Oracle 提供好几种性能分析的报告，常用的是 AWR、ADDM.
| 工具 | 作用 | 类比 |
|---|---|---|
| AWR | 关注数据库的整体性能报告 | 体检报告 |
| ASH | ASH 是针对数据库中的等待事件与那些 Sql 具体对应 | 胃镜 |
| ADDM | Oracle 给出的一些建议 | 病历卡记录 |
| AWRDD | 针对不同时段的性能的一个比对报告 | 医生分析前后两次体检报告的动作 |
| AWRSQ | 具体某个 Sql 的执行计划，可以保存多个执行。 | 活检 |
分析问题首先, 获取 AWR 报告及 ADDM 报告,
获取方式
对于 Oracle 数据库可以使用 sqlplus 或者 plsql developer 客户端软件
sqlplus 方式参考 Oracle 分析报告及重置统计信息
plsql developer 也可以使用，登录之后，选择文件 (File)-> 新建 (New)-> 命令窗口 (Command Window)
生成 AWR 报告的时候，需要使用本地的 awrrpt.sql 生成，比如
@D:\oracle\product\11.0.4\RDBMS\ADMIN\awrrpt.sql
生成报告类型，默认 html 格式，直接回车即可
如果是本地执行, 如果没有安装 Oracle 客户端,
可以拷贝ADMIN 文件夹到 instantclient 工具中如图:
执行
@D:\kimpath\instantclient_12_1\ADMIN\awrrpt.sql
@D:\kimpath\instantclient_12_1\ADMIN\addmrpt.sql
| 报告 | 关注点 | 类比 | 命令 | 关注点 |
|---|---|---|---|---|
| AWR | 关注数据库的整体性能报告 | 体检报告 | “@?/rdbms/admin/awrrpt.sql” | load_profile |
| ASH | ASH 是针对数据库中的等待事件与那些 Sql 具体对应 | 胃镜 | “@?/rdbms/admin/ashrpt.sql” | 等待事件与具体的 Sql 完美结合 |
| ADDM | Oracle 给出的一些建议 | 病历卡记录 | “@?/rdbms/admin/addmrpt.sql” | 整体性的建议 |
| AWRDD | 针对不同时段的性能的一个比对报告 | 医生分析前后两次体检报告的动作 | “@?/rdbms/admin/awrddrpt.sql” | 不同时期 load profile |
| AWRSQ | 具体某个 Sql 的执行计划，可以保存多个执行。 | 活检 | “@?/rdbms/admin/awrsqrpt.sql” | Plan statistics |
AWR 关注点
-
AWR 关注点 1 之 DB TimeDB Time
-
这个指标主要用来判断当前系统有没有遇到相关瓶颈，是否较为繁忙导致等待时长很长。一般来说，Elapsed 时间乘以 CPU 个数的时间如果结果大于 DB Time，我们认为系统压力不大，反之则压力较大。如下例子中，60.11×64=3847.04<5990.6，说明系统现在还是比较繁忙的。
-
load_profile 这个指标主要用来展现当前系统的一些指示性能的总体参数，比如经典的 Redo size 就是用来显示平均每秒的日志尺寸和平均每个事务的日志尺寸，结合 Transactions 这个每秒事务数的指标，就可以分析出当前事务的繁忙程度。
-
如每秒有 6777.1 个事务数，这在现实中几乎不可能，现实中的运营商系统一般在 200 上下比较正常，超过 1000 就属于非常繁忙了。
-
efficiency percentages 是一些命中率指标，其中 Buffer Hit、Library Hit 等都表示 SGA（System global area）的命中率。在下图中 Soft Parse 指标表示共享池的软解析率，在 OLTP 系统中如果该指标低于 90% 应当引起你的注意，这表示存在未使用绑定变量的情况。我们通过比对两个报告，可以看出明显差异，如下面系列图所示。
-
等待事件是衡量数据库整体优化情况的重要指标，通过观察 Top 5 Timed Foreground Events 模块的 Event 和 %DB time 两列，可以非常直观地看出当前数据库面临的主要等待事件是什么。下图两个例子分别告诉我们数据库面临锁等待和日志切换等待的情形。
-
SQL Statistics 分别从几个维度来罗列出 TOP 的 SQL，这是一种简单粗暴但有效的方法。看看执行时长，直接拿出来优化一般都是对的做法