oracle中能用real吗,Oracle SQL 调优利器之Oracle Real-Time SQL Monitor

【Real-Time SQL Monitor 初解】

在Oracle数据库的性能调优中，绝大部分的性能问题最后都可以追溯到SQL的执行性能上。单个SQL的执行性能低下，伴随着执行次数的增加可能将整个数据库都拖垮。

而面对突发的SQL性能问题也许老司机能够快速地通过查看真实的执行计划 xplan from cursor这些方式分析执行计划的瓶颈。

然后有针对性地做出相应的整个措施。然而这需要较为深厚的优化功底，而 Oracle 11gr2 中的Real-Time SQL Monitor却是给新手调优带来的一大利器。

我们先来认识一下这位神秘的优化助手:

▪ real-time sql monitor 会去自动monitor执行时间在CPU/IO 上累积耗费超高5s 或者并行执行的SQL语句。当然某些wait 时间不到 5s 的SQL 也可以通过加 /*+ monitor */ 来monitor。

▪这里主要涉及到两个动态性能视图V$SQL_MONITOR和V$SQL_PLAN_MONITOR。

▪一旦数据库出发了monitor操作，便会向视图 V$SQL_MONITOR 中插入一行记录。

这条记录包含了太多的信息：如SQL 当前已经执行的逝去时间，CPU上的等待时长，IO上的等待时长，读写的次数以及其他等待的信息。

如果SQL本身还处于执行状态，这个视图的信息每秒都会更新一次上面的信息。 V$SQL_MONITOR 视图中的信息只有在空间需要重复使用的时候才会被删掉。 基本上查询的时候都可以查到。

▪V$SQL_MONITOR 不像 V$SQL那样是一个累积的记录值。

在 V$SQL_MONITOR中没执行一个SQL(符合monitor条件)都会是一条独立的记录。这对相同sql文本具有不同执行计划，或者相同执行计划性能却又非常大差异的调优是很方便我们甄别的。

甚至在相同sql 在不同 session 通过不同的bind value发起的sql 查询都可能存在很大的性能差异。这些都可以通过sql monitor很容易的甄别。

【如何查看一份完整的monitor报告？】

Oracle 将该功能集成在了SQL TUNNING中，通过dbms_sqltune.report_sql_monitor可以查看具体的sql执行情况。

提供的可选参数非常多,下面列举几个常见的参数做一下分析：

▲ sql_id 作为一段 sql 的唯一标识，一般需要提供。默认为空，不提供该参数的值的时候，Oracle默认提供最后一次备monitor的sql报告。

▲session_id,session_serial 一般需要同时使用，当出现两个session 执行同一段 sql 文本出现不能的性能表现时可以通过 session_id,session_serial区别报告。

▲inst_id 指定报告检阅的实例。 -1 表示当前实例，默认为空表示所有实例。

▲sql_plan_hash_value 分析指定执行计划的执行细节，指定具体的phv值。

▲type 提供多种输出类型，有html,active,text。建议使用text 方便展示和复制,text也为默认值。

【sql monitor报告演示】

现在是刚执行完，可以直接通过包来获取默认参数。这是测试环境没有其他monitor，那么最后一次即为这次查询。

若在真实的生产环境中需要查询出sql_id 传参数给函数。

从报告中可以看出：

1. sql 的执行状态为DONE，表示已经执行结束。若还在执行则为EXECUTING。

2. 当前 sql 执行的耗时 Duration。未执行完的sql 这个的数值会持续变化。

3. 执行该sql的用户名及 session_id,serial_id。

4. 绑定变量的信息，这对sql的调优其实是很重要的。特别是在绑定变量窥视及列的数据分布倾斜的情况下需要结合具体的变量值去分析。

5. Golbal Stats 反应真实的资源消耗情况。执行时间，在CPU上的时间，在IO上的时间及逻辑读。 若有大量的temp读写操作时，这里也会有相应的体现。

6. 执行计划部分，可以看到真实的执行路径，基于统计信息的评估值和实际执行情况。对于上百行的执行计划可以快速定位执行的瓶颈。

【精选案例分析】

某资管测试环境运行一句简单的多视图查询无法正常查询出结果，最后都以temp被耗尽报错告终。

▪通过sql monitor发现运行到114s 的时候就报错 ORA-01652 TEMP无法扩展。

▪观察Golbal Stats大部分时间消耗在了CPU上。

▪Golabl Stats 显示在114s中该SQL写入temp大约5GB的数据。

▪执行计划显示在执行计划ID 5  HASH JOIN 中消耗大量的CPU和TEMP空间。

▪通过hint 禁用 hash join 执行时间降低到8s出结果。

版权所有 侵权必究

如需转载请联系

0571-28829811