如何通过日志或gv$sql_audit，分析OceanBase运行时的异常SQL

本文作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。本文约 2000 字，预计阅读需要 8 分钟。

简介

在 OCP 云平台的 Top SQL 界面中，能观察到异常SQL，但这些SQL并未明确显示具体的报错原因，或者提供了报错原因，但还不够详细。

本文以 SQL 异常重试的案例，通过 日志文件 和 gv$sql_aduit 视图 这两种方法，分析并确定OceanBase运行过程中，出现报错的具体原因。

建议在 PC 端浏本文~

背景

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

文中后半部分对此场景进行延伸。

假设 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
错误码：6005
更新某行数据失败：failed to update row (xxx)

6. 写写冲突部分日志

#  grep -i "YB420ABA40A1-000615A29EDEEA36-0-0" observer.log.2024040916* | grep "lock_for_write conflict"

点击放大

7. 确认行为

确认此 trace_id 关联的 SQL 存在重试行为。

# grep -i "YB420ABA40A1-000615A29EDEEA36-0-0" observer.log.2024040916* | grep -i "will retry"

8. 错误码含义

错误码 6005：更新操作加锁失败

错误码 6003：等待锁超时

错误码 6212：SQL 语句超时

对于语句超时的情况，首先要确定当前租户下 ob_query_timeout 变量设置，然后根据 trace_id 搜索 observer.log 日志，找到当前语句的 cur_query_start_time。

如果 超时时间点 - cur_query_start_time = ob_query_timeout，说明是符合预期的。下面来验证一下。

查询租户变量 ob_query_timeout 为 10s。

在 observer.log 中检索此 trace_id 的起始时间。

开始时间：

# grep -i "YB420ABA40A1-000615A29EDEEA36-0-0" observer.log.20240409* | grep -m 1 "cur_query_start_time"

超时时间：

# grep -i "YB420ABA40A1-000615A29EDEEA36-0-0" observer.log.20240409* | grep "timeout_timestamp" | tail -n 1

可以看到超时时间减去开始时间等于 10s，说明此处超时行为符合预期。

问题总结

当执行 SQL UPDATE evan.evan_zheng SET name = 'test0409' WHERE id = 1； 更新操作加锁失败，达到当前租户 ob_query_timeout 变量设置的值（10s）触发 6212 报错（语句超时）回滚语句。

可能造成此问题的原因：

业务使用了较大的超时时间，且存在一个会话中的未知长事务持有锁，阻塞了其他事务的执行。
开发人员并发更新同一行数据，并发处理逻辑存在错误。

优化措施

合理设置超时变量时间。
合理设置程序代码并发控制逻辑。
关注长事务告警。

延伸场景

如果 SQL 正在持续重试中，且 gv$sql_audit 视图信息未被清除，可参考如下步骤进行排查。

1. OCP 云平台，复制 SQL ID

2. 基于 SQL ID 查看主要的错误代码

可以看到 4012，6003 等超时相关错误码。

select/*+ PARALLEL(8)*/trace_id,sid,tenant_name,svr_ip,svr_port,retry_cnt,ret_code,query_sql,usec_to_time(request_time) as start_time
fromgv$sql_audit
wheresql_id = 'D884EA797E73F466819BAE2AE4AC1FE1'and retry_cnt > 1
group byret_code
order byretry_cnt desc;

3. 查看 session_id

select/*+ PARALLEL(8)*/trace_id,sid,tenant_name,svr_ip,svr_port,retry_cnt,ret_code,query_sql,usec_to_time(request_time) as start_time
fromgv$sql_audit
wheresql_id = 'D884EA797E73F466819BAE2AE4AC1FE1'
group bysid
order byrequest_time desc;

4. 查询 table_id

selectdatabase_name,table_id,table_name,tenant_id,tenant_name
fromoceanbase.gv$table
wheretenant_id = 1001and database_name = 'evan'and table_name = 'evan_zheng';

5. 查询锁持有者事务信息

使用 sys 租户执行。

select * from __all_virtual_trans_lock_stat where table_id = '1100611139453778'\G

6. 查询锁等待者事务信息