【技巧分享】SQL 执行报错问题排查方法

[OceanBase文档]

在数据库运维中，SQL 执行报错非常常见而且可能对业务造成直接影响。 SQL 执行报错的原因有很多，比如没能正确连接到数据库、数据库用户权限不足、语法错误或数据不满足查询条件等等。

为了帮助大家快速定位问题根源并高效解决，这里总结了一套清晰、实用的 SQL 报错排查流程。这套流程提供明确的操作步骤，旨在提升问题处理效率，尽可能降低对业务的影响，为日常运维工作提供有力的支持。

下图是 SQL 执行报错问题排查流程图。

流程介绍

当遇到执行 SQL 报错的场景，可以按照该流程进行问题排查。

查看 SQL 报错信息，如果报错信息包含明确的错误码，请结合错误码信息进行问题排查；如果缺少明确的错误码，请判断错误类型：应用执行报错、手动执行 SQL 报错。

1. 如果是应用执行报错，请参见应用异常问题排查。
2. 如果是手动执行 SQL 报错，判断是否可以手动复现，不可复现，请参见其他场景问题排查；可复现，先复现问题场景。根据原场景，通过 2881 或 2883 端口连接 OB 集群，执行原 SQL 语句复现问题场景。

复现 SQL 报错场景后，按照如下步骤收集相关信息进行问题排查。

1. 先获取 trace_id。
   注意：必须执行完报错 SQL 后，第一时间执行以下语句；否则查出来的不是报错 SQL。

   • Oracle 租户，执行 select last_trace_id() from dual;
   • MySQL 租户，执行 select last_trace_id;

2. 获取实际执行 SQL 的主机信息。
   OB 集群一般是多节点部署，可以通过如下 SQL 获取 SQL 实际执行的节点，然后再进行日志过滤。根据 sql_audit 视图查询结果，svr_ip 对应的主机即实际执行该 SQL 主机。

   • V2.x 版本和 V3.x 版本，执行select * from oceanbase.gv$sql_audit where trace_id='第二步获取的trace_id';
   • V4.x 版本执行 select * from oceanbase.gv$ob_sql_audit where trace_id='第二步获取的trace_id';

3. 使用 ssh 命令登录到对应的主机。

4. 使用 cd 命令进入对应的日志文件夹。
   命令如下：cd /home/admin/oceanbase/log。

5. 执行如下命令过滤日志中相关信息。
   命令如下：grep “${trace_id}” observer.log observer.log.xxxx

根据日志提供的信息，结合错误码或相关错误提示信息等进行问题分析。更多日志信息，请参考日志概述；更多错误码信息，请参考 错误信息概述。如遇日志中信息不明确，可以联系技术支持人员一起排查。

以上为 SQL 执行报错问题排查流程，希望能为日常运维工作提供有力的支持。

典型案例

MySQL 模式

• SQL 复现后，数据库回显有错误码信息

  • 执行查询 JSON SQL，错误码 ERROR 5676 (HY000) ，请参见

执行查询 JSON SQL 报错 the interval is invalid。

• 当 SELECT 语句中包含较多的 OR 条件，或者大量 AND 连接的 IN 条件，或者大量的 AND NOT 条件时，执行 SELECT 报错 -4013，No memory or reach tenant memory limit 。请参见 SQL 解析阶段报错 -4013，租户内存满。

• 日志中有错误码信息

  • 在可重复读的隔离级别下，业务执行过程中日志报错 ERROR 6235 (25000) ，请参见

OceanBase 数据库执行 SQL 报错 Can’t serialize access for this transaction。

• OCP 监控平台告警报磁盘剩余空间不足 disk is almost full(ret=-4184) ，错误码 4184 ，请参见 SQL 查询导致磁盘空间不足报错 -4184。
• 执行 SQL 对一个 longtext 字段进行处理时报错 ErrorCode=5098 ，请参见

SQL 报错：Varchar value is too long for the column。

• 出现大量慢 SQL 重试的情况，且日志信息包含 errcode=-5307 ，请参见 SQL 执行报错 errcode=-5307。
• 因 sql_work_area 不足导致 SQL 报错 -4013，请参见

因 sql_work_area 不足导致 SQL 报错 -4013 的原因和解决方法。

• SQL 执行报错 error 4119 (RPC packet to send too long) 。通过 trace_id 查询 observer.log 可以看到信息 obrpc packet payload execced its limit ，请参见 SQL 执行报错 -4119，RPC packet to send too long。

• 日志中有其他报错信息

  • 应用端批量执行 SQL 语句时报错进行问题排查时，请参见 批量执行 SQL 报错。
  • SQL 语句的过滤条件里，非同一个字段的判断条件超过 64 个时报错 -4002 Invalid argument ，请参见 SQL 语句过滤条件里存在非同一字段判断条件超过 64 个报错 -4002。

Oralce 模式

• SQL 复现后，数据库回显有错误码信息

  • 执行 update 向量形式的子查询时，使用 explain sql 命令解析语句时报错 ORA-00600 ，请参见 explain SQL 报错 4000。
  • SQL 执行报错误代码 5001 ，请参见 SQL 执行报错 unexpected STRING_VALUE ret=-5001。
  • 对于一条含 c1,c2,c3 列的查询语句，如果列 c1,c2 命中索引，且 c1 或 c2 列上有多个 in 表达式，c1/c2/c3 任意组成一个向量表达式，那么在执行的时候就会报 internal error ，错误码 ORA-00600 ，请参见含多个 in 和向量表达式的 SQL 执行报错 4016。

• SQL 有错误码，结合日志中错误码信息

  • OceanBase 数据库 V3.x 版本中 Oracle 租户执行包含 regexp_replace 复杂表达式 SQL 报错 ORA-00600 ，请参见 OceanBase 数据库 V3.x 版本中 Oracle 租户执行包含 regexp_replace 复杂表达式时 SQL 报错 -4013 的原因和解决方法。
  • 执行 SQL 报错 Timeout，错误码 ORA-00600 ，请参见 SQL 执行报错 timeout。

• 日志中有其他报错信息

  • 业务 SQL 子查询包含相同的列名，PS 执行报错 field list ambiguously defined 。请参见 业务 SQL 子查询包含相同的列名，PS 执行报错 field list ambiguously defined。

相关文档

• 查找特定 SQL 请求的日志
• 基于 Trace 功能查找上一次 SQL 请求日志
• 日志概述

[Coca-cola]

思路很好啊！收藏了！

[OB社区小助手]

赞！OceanBase 官方文档团队终于又在社区论坛登场了！

期待这个专业选手能够在这里持续地为用户们分享更多的技术内容！

大家也抓紧在贴子里给她们提需求！

[靖顺]

有点东西

[OB社区小助手]

同样都是专业选手，你看看人家！

[mittens]

很棒的帖子，收藏一下。

[AntTech_FYPTIV]

解决报错信息，最好分析日志

[独善其身]

一直想自己总结一下这块的思维导图

[兹拉坦]

感谢官方文档团队为大家提供问题排查的方法！

期待在这个新板块继续和大家分享更多的问题排查文档！

这里再啰嗦一句：select last_trace_id() 在使用上有一些限制，必须要在在同一个 session 中，紧接着报错的 SQL，去执行 select last_trace_id()。 如果在报错 SQL 之后，已经执行了其他 SQL，或者已经退出对应 session，可以在日志里先通过 grep "ret=-errno" 或者直接 grep 你执行的 SQL 里的关键字，也是可获取到 trace_id 的。还有就是 OCP 白屏捞日志超级方便，且可以更便捷地选择日志级别和日志的时间范围，也是捞日志的一种好方法。

参考：【如何提问】遇到 OBServer 中的非预期报错，应该如何发帖提问？

[兹拉坦]

今天刚发现 show trace 命令还可以看到执行失败的 SQL，是在什么时候失败的。这可能对排查问题会有一些帮助，也一起在这里分享给大家。

比如下面这个例子，可以看到表不存在这个报错，让 SQL 在 resolver（解析）阶段就停下来了。说明是在 resolver 的检查时就发现了表不存在，然后就没有执行后面的东西了。个人理解 trace 树的最后一步就是出错的地方。

obclient> set ob_enable_show_trace = 1;
Query OK, 0 rows affected (0.00 sec)

obclient> insert into z0case(z0_test0,z0_test1) values('11:11:12', '11:11:10');
ERROR 1146 (42S02): Table 'test.z0case' doesn't exist

obclient> show trace;
+-------------------------------+----------------------------+------------+
| Operation                     | StartTime                  | ElapseTime |
+-------------------------------+----------------------------+------------+
| com_query_process             | 2025-05-09 10:19:39.621982 | 0.551 ms   |
| └── mpquery_single_stmt       | 2025-05-09 10:19:39.621988 | 0.534 ms   |
|     └── sql_compile           | 2025-05-09 10:19:39.621997 | 0.405 ms   |
|         ├── pc_get_plan       | 2025-05-09 10:19:39.622002 | 0.009 ms   |
|         └── hard_parse        | 2025-05-09 10:19:39.622063 | 0.315 ms   |
|             ├── parse         | 2025-05-09 10:19:39.622063 | 0.079 ms   |
|             └── resolve       | 2025-05-09 10:19:39.622170 | 0.180 ms   |
+-------------------------------+----------------------------+------------+
7 rows in set (0.01 sec)

[兹拉坦]

顺哥要不要考虑在这个板块给大家介绍下怎么通过 obdiag 捞日志和分析问题？

[皇甫侯]

思维导图很棒，看着就很清晰

[zmix]

[甯空]

太赞，保存做桌面。

[ob-tiger]

过程很清晰

[胖胖兔]

学习

[EINTR]

太强了,学习

[mittens]

很棒的分享

[AntTech_BUMK07]

[AntTech_GuiBin]

赞赞赞