(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 - 20M | avail_mem_limit - 40M |
[100M, 5G] | availmem_limit * 0.8 | availmem_limit * 0.6 | |
[5G, +∞] | availmem_limit - 1G | availmem_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 | 记录上一个阶段点到这次阶段点执行耗时 |
查看各阶段耗时