SQL 执行报错问题排查

SQL 执行报错问题排查

更新时间：2026-04-10 12:01:00

编辑

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

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

SQL 执行报错问题排查流程如下图所示。

SQL 执行报错问题排查流程

流程介绍

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

执行 SQL 报错后，需要先查看 SQL 报错信息，如果报错信息中包含明确的错误码，请结合错误码信息进行问题排查；如果缺少明确的错误码，需要判断该问题的错误类型，确定是应用执行报错，还是手动执行 SQL 报错：

如果是应用执行报错，具体排查方法参见应用异常--错误信息中不包含 OceanBase 错误码和应用异常--错误信息中包含 OceanBase 错误码。
如果是手动执行 SQL 报错，判断是否可以手动复现。
1. 如果不可以复现，请结合 SQL 语句在知识库文档中搜索相关内容进行参考排查。
2. 如果可以复现，先复现问题场景。根据原场景，通过 2881 或 2883 端口连接 OceanBase 集群，执行原 SQL 语句复现问题场景。
  
  复现 SQL 报错场景后，按照以下步骤收集相关信息进行问题排查。
  1. 执行以下语句，获取 trace_id。
    
    注意
    
    必须在执行完报错 SQL 后，第一时间执行以下语句；否则，查询出来的不是报错 SQL 的 trace_id。
    MySQL 模式
    
    Oracle 模式
    MySQL 模式下获取 trace_id 的语句如下：
    
    obclient> SELECT last_trace_id();
    
    Oracle 模式下获取 trace_id 的语句如下：
    
    obclient> SELECT last_trace_id() FROM DUAL;
  2. 根据获取的 trace_id 获取实际执行该 SQL 的主机信息。
    
    OceanBase 集群一般为多节点部署，可以通过如下 SQL 获取 SQL 实际执行的节点，然后再进行日志过滤。
    MySQL 模式
    
    Oracle 模式
    MySQL 模式下执行以下语句：
    
    obclient> SELECT * FROM oceanbase.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;
    
    其中，last_trace_id 需要替换为上一步获取的 trace_id。
    
    Oracle 模式下执行以下语句：
    
    obclient> SELECT * FROM SYS.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;
    
    其中，last_trace_id 需要替换为上一步获取的 trace_id。
    根据 GV$OB_SQL_AUDIT 视图的查询结果，svr_ip 对应的主机即实际执行该 SQL 的主机。
  3. 根据获取的主机信息，使用 ssh 命令，登录到对应的主机。
  4. 进入日志所在目录。
    
    以下以 OceanBase 数据库的安装目录为 /home/admin/oceanbase 为例，日志的具体存放路径请以实际环境为主。
```
cd /home/admin/oceanbase/log
```
  5. 执行以下命令，过滤日志中的相关信息。
```
grep "${trace_id}" observer.log
```
```
grep "${trace_id}" observer.log.xxx
```
    其中，${trace_id} 需要替换为前面步骤中获取的 trace_id；observer.log.xxx 为带时间戳的日志文件，xxx 需要根据复现 SQL 报错的时间替换为实际时间戳。
  6. 根据日志提供的信息，结合错误码或相关错误提示信息等进行问题分析。
    
    更多日志及错误码相关的介绍，参见日志概述和错误信息概述。
    
    如遇日志中信息不明确，请联系技术支持人员协助排查。

典型案例

以下为部分典型的 SQL 执行报错问题排查案例。

MySQL 模式

Oracle 模式

SQL 报错复现后，数据库返回结果中有错误码信息
- 当 SELECT 语句中包含较多的 OR 条件，或者大量 AND 连接的 IN 条件，或者大量的 AND NOT 条件时，执行 SELECT 语句报错 -4013，No memory or reach tenant memory limit。具体排查操作参见 SQL 解析阶段报错 -4013，租户内存满。
日志中含有错误码信息
- 执行 SQL 语句对一个 longtext 类型的字段进行处理时，报错 ErrorCode=5098。具体排查操作参见 SQL 报错：Varchar value is too long for the column。
- 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 语句的过滤条件里，非同一个字段的判断条件超过 64 个时，报错 -4002 Invalid argument。具体排查操作参见 SQL 语句过滤条件里存在非同一字段判断条件超过 64 个报错 -4002。

SQL 报错复现后，数据库返回结果中有错误码信息
- 一条含 c1,c2,c3 列的查询语句，其中列 c1,c2 命中索引，且 c1 或 c2 列上有多个 in 表达式，c1/c2/c3 任意组成一个向量表达式，在执行该语句时报 internal error，错误码 ORA-00600。具体排查操作参见含多个 in 和向量表达式的 SQL 执行报错 4016。
SQL 执行后有错误码，结合日志中的错误码信息
- 执行 SQL 语句时报错 Timeout，错误码 ORA-00600。具体排查操作参见 SQL 执行报错 timeout。

流程介绍

注意

典型案例

相关文档