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

在数据库运维中,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 的原因和解决方法

Oralce 模式

相关文档

15 个赞

思路很好啊!收藏了! :+1: :+1:

13 个赞

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

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

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

13 个赞

有点东西 :100:

13 个赞

同样都是专业选手,你看看人家!

10 个赞

很棒的帖子,收藏一下。

6 个赞

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

6 个赞

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

5 个赞

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

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

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

参考:【如何提问】遇到 OBServer 中的非预期报错,应该如何发帖提问?

6 个赞

今天刚发现 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)
4 个赞

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

5 个赞

思维导图很棒,看着就很清晰 :clap: :clap:

5 个赞

:+1: :+1: :+1:

3 个赞

太赞,保存做桌面。

3 个赞

过程很清晰 :+1: :+1: :+1:

3 个赞

学习

2 个赞

太强了,学习