基于日志或 gv$sql_audit 分析 OB 异常重试 SQL

本文以 SQL 异常重试场景为例，使用基于 日志文件 和 gv$sql_aduit 视图 这两种方式，找出具体的报错原因。

作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 2000 字，预计阅读需要 8 分钟。

简介

我们在 OCP 云平台 Top SQL 界面看到一些异常 SQL，但并未提示具体报错原因或提示了原因但不够详细。

本文以 SQL 异常重试场景为例，使用基于 日志文件 和 gv$sql_aduit 视图 这两种方式，找出具体的报错原因。

本文更推荐 PC 端浏览~

背景

1. OceanBase 3.X 企业版 MySQL 模式
2. 某客户在性能压测过程中反馈，在对某张表 UPDATE 时响应缓慢，一直无法执行成功。
3. gv$sql_aduit 关于此 SQL 相关信息已被清理，且 Top SQL 未提示报错具体原因，只能基于日志文件进行排查。
4. OCP 云平台查看初始状态如下：
   • UPDATE 语句重试 440 次
   • 平均响应时间为 5491.15 ms

5. 文中后半部分对此场景进行延伸。
   • 假设 SQL 正处于异常重试状态中，且关联的 gv$sql_audit 视图信息未被清除的情况下，如何展开排查提供思路。

排查过程

1. 导出 Top SQL

列管理 按需勾选需查看的信息（如：SQL ID，重试次数）。

2. 复制 SQL 文本

3. 查找 UPDATE 语句

在对应的服务器上 grep 此 SQL 语句的打印次数：

• 结果为 1 小时内执行了 505 次，判断针对该行数据的 UPDATE 行为可能存在异常。
• 日志打印 SQL 次数可能与 Top SQL 不同，大致对应上即可。
• 一般异常 SQL 会在 observer.log 中打印，正常执行完成的可能不会存在记录。

# grep -i "UPDATE evan.evan_zheng SET name = 'test0409' WHERE id = 1" observer.log.2024040916* | wc -l
505

4. 查找错误位置

以 SQL 语句 和 ret= 作为条件进行检索，看是否存在相关错误码。

• 若 SQL 文本无法精准匹配，则只复制部分关键字。
• 可以看到 4012，6003 等超时相关错误码。
• 复制一条 trace id 用于检索

# grep -i "UPDATE evan.evan_zheng SET name = 'test0409' WHERE id = 1" observer.log.2024040916* | grep "ret="

5. 查看报错信息

检索 trace_id，查看主要报错信息。

• 写写冲突：on_wlock_retry、lock_for_write conflict
• 错误码