OceanBase 分析 RT 突然抖动的 SQL

推荐使用外部诊断工具 Tars 进行问题分析,或者使用 ​(g)v$sql_audit​ 视图进行问题排查。

使用 ​(g)v$sql_audit​ 进行问题排查方式如下:

  1. 在线上如果出现 RT 抖动,但 RT 并不是持续很高的情况,可以考虑在抖动出现后,立刻将 sql_audit 关闭 ​(alter system set ob_enable_sql_audit = 0)​,从而确保该抖动的 SQL 请求在 sql_audit 中存在。
  2. 通过 SQL Audit 查询抖动附近那段时间 RT 的 TOP N 请求,分析有异常的 SQL。
  3. 找到对应的 RT 异常请求,则可以分析该请求在 sql_audit 中的记录进行问题排查:
    • 查看 retry 次数是否很多(​RETRY_CNT​ 字段),如果次数很多,则可能有锁冲突或切主等情况。
    • 查看 queue time 的值是否过大(​QUEUE_TIME​ 字段)。
    • 查看获取执行计划时间(​GET_PLAN_TIME​ 字段),如果时间很长,一般会出现 ​IS_HIT_PLAN = 0​,表示没有命中 plan cache。
    • 查看 EXECUTE_TIME 的值,如果值过大,则可以通过以下步骤进行排查:

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

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

逻辑读次数 = 2 * ROW_CACHE_HIT 
           + 2 * BLOOM_FILTER_CACHE_HIT 
           + BLOCK_INDEX_CACHE_HIT 
           + BLOCK_CACHE_HIT + DISK_READS

如果在 SQL Audit 中 RT 抖动的请求数据已被淘汰,则需要查看 OBServer 中抖动时间点是否有慢查询的 trace 日志,并分析对应的 trace 日志。

作者:冒牌SEO,如若转载,请注明出处:https://www.web176.com/oceanbase/26128.html

(0)
打赏 支付宝 支付宝 微信 微信
冒牌SEO冒牌SEO
上一篇 2023年10月14日
下一篇 2023年10月14日

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注