OBCP第四章 SQL调优-SQL执行性能监控

(g)v$sql_audit

全局 SQL 审计表

基于虚拟表__all_virtual_sql_audit的视图， 该虚拟表对应的数据存放在一个可配置的内存空间中

由于存放这些记录的内存是有限的，因此到达一定内存使用量，会触发淘汰

可以用来查看每次请求客户端来源，执行 server 信息，执行状态信息，等待事件及执行各阶段耗时等

是按照租户拆分的，除了系统租户，其他租户不能跨租户查询

sql_audit 相关设置

设置 sql_audit 使用开关

alter system set enable_sql_audit = true/false;

设置 sql_audit 内存上限，默认内存上限为3G，可设置范围为 [64M,+∞]

alter system set sql_audit_memory_limit = '3G';

(g)v$sql_audit看什么

retry次数是否很多(RETRY_CNT字段）,如果次数很多，则可能有锁冲突或切主等情况

queue time 的值是否过大(QUEUE_TIME 字段)，很高表明CPU资源不够用

获取执行计划时间(GET_PLAN_TIME), 如果时间很长，一般会伴随IS_HIT_PLAN ＝0,表示没有命中plan cache

查看EXECUTE_TIME值，如果值过大，则：

查看是否有很长等待事件耗时

分析逻辑读次数是否异常多(突然有大账户时可能会出现）

SQL audit记录的等待事件如下相关信息：

记录了4大类等待事件分别的耗时（APPLICATION_WAIT_TIME, CONCURRENCY_WAIT_TIME,USER_IO_WAIT_TIME,SCHEDULE_TIME),每类等待事件都涉及很多具体的等待事件

记录了耗时最多的等待事件名称（EVENT）及该等待事件耗时（WAIT_TIME_MICRO）

记录了所有等待事件发生的次数（TOTAL_WAITS）及所有等待事件总耗时（TOTAL_WAIT_TIME_MICRO）

(g)v$sql_audit淘汰机制

淘汰机制启动间隔

后台任务每隔 1s 会检测是否需要淘汰。

sql_audit 内存最大可使用上限

avail_mem_limit = min(OBServer可使用内存*10%, sql_audit_memory_limit)

淘汰/停止淘汰触发标准

SQL Trace

SQL Trace能够交互式的提供上一次执行的SQL请求执行过程信息及各阶段的耗时。

SQL Trace开关

SQL Trace功能默认时关闭的，可通过session变量来控制其关闭和打开。

set ob_enable_trace_log = 0/1;

Show Trace

当 SQL Trace功能打开后，执行需要诊断的SQL，然后通过show trace能够查看该SQL执行的信息。这些执行信息以表格方式输出，每列说明如下：

查看各阶段耗时