【 使用环境 】 测试环境
【 OB or 其他组件 】数据库，odp
【 使用版本 】ob3.x
【问题描述】oceanbase数据库在某个时间段下，该实例下所有数据库查询耗时变的很高，过了这个时间段又恢复了，你们会去怎么查,请求各位大佬给个思路。
查 SQL 审计视图 oceanbase.gv$sql_audit 。反复查询，修改条件，缩小范围，找到 某个 sql 前后几次执行耗时不一样，再分析。
时效性有限，取决于 节点内存和租户内存大小。
select usec_to_time(request_time) req_time, svr_ip, plan_id, client_ip, user_client_ip, tenant_name, user_name, database_name,query_sql, ret_code, elapsed_time,execute_time,queue_time, affected_rows, return_rows,partition_cnt, event
from gv$sql_audit
where sql_id='306B591840B16FEB25187973ADFA677B';
后面就是分析 执行计划、节点负载等等。
更多思路参考：https://mp.weixin.qq.com/s/9m1qZmnSpo5wuTZvcty56A
2 个赞
是指时间范围吗，我通过日志找到的，在15点的时候，同一条sql查询耗时10秒左右，16点的时候就只需要零点几秒了
oceanbase.gv$sql_audit 相对友好一点，做第一轮分析判断，发一些初步信息。
日志里看 obproxy_slow.log, obproxy.log 也会有一些线索，相对麻烦一些。
如果撇开外部因素变化（如网络性能变化），最终还是会回到 数据库层面分析 执行计划。
1 个赞
大佬，已经查出问题了，是cpu打满的原因，查为什么会被打满，是oms在那个时间段建立了同步链路导致发送了大量查询语句，把cpu给打满了。现在有个疑问，oms同步的时候，会在哪个阶段发送大量查询语句呢，增量同步的时候吗？还是一开始结构同步的时候就开始查询了。oms同步的是百库百表