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_audit 内存最大可使 用上限 (avail_mem_limit)[64M, 100M]avail_mem_limit - 20Mavail_mem_limit - 40M
[100M, 5G]availmem_limit * 0.8availmem_limit * 0.6
[5G, +∞]availmem_limit - 1Gavailmem_limit-2G
sql_audidt记录数上限/超过900w条记录达到800w条记录

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执行的信息。这些执行信息以表格方式输出,每列说明如下:

列名说明
Title记录执行过程某一个阶段点
KeyValue记录某一个阶段点产生的一些执行信息
Time记录上一个阶段点到这次阶段点执行耗时

查看各阶段耗时

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

柯西极限存在准则

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值