应用异常--错误信息中包含 OceanBase 错误码

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

数据库在运行期间经常会有各种异常情况出现，例如，应用程序错误、数据库连接错误、数据库权限问题、数据库资源问题、网络问题等。在这所有的情况中，有一种就是应用异常，但是错误信息中包含 OceanBase 错误码。

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

应用执行报错且错误信息中包含 OceanBase 错误码的问题排查流程如下图所示。

应用异常报错包含OB错误码的排查流程

流程介绍

当遇到应用执行异常且报错信息中包含 OceanBase 错误码信息的场景，可以按照该流程进行问题排查。

首先要判断是否可以使用 OBClient 连接数据库后手动复现问题：

是，则可以通过连接待问题复现后进行进一步排查。
否，则需要排查程序配置的数据源信息。

通过复现问题进行问题排查

使用 OBClient 通过 2881（SQL 端口号，默认为 2881，如果是自定义，请替换为实际端口号）连接 OceanBase 集群。
手动执行报错的 SQL 复现问题场景。
执行以下语句，获取 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;
获取实际执行 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 的主机。
根据获取的主机信息，使用 ssh 命令，登录到对应的主机。
进入日志所在目录。

以下以 OceanBase 数据库的安装目录为 /home/admin/oceanbase 为例，日志的具体存放路径请以实际环境为主。
```
cd /home/admin/oceanbase/log
```
执行以下命令，过滤日志中的相关信息。
```
grep "${trace_id}" observer.log
```
```
grep "${trace_id}" observer.log.xxx
```
其中，${trace_id} 需要替换为前面步骤中获取的 trace_id；observer.log.xxx 为带时间戳的日志文件，xxx 需要根据复现 SQL 报错的时间替换为实际时间戳。
根据日志提供的信息，结合相关错误提示信息等进行问题分析。

更多日志相关的介绍，参见日志概述。如遇日志中信息不明确，请联系技术支持人员协助排查。

排查程序配置的数据源信息

根据数据源明确访问链路。
明确访问链路包含如下信息的数量的地址。
- OBProxy 的数量与地址信息
- OBServer 主机的数量与地址信息
判断是否经过 OBProxy。
- 是，经过 OBProxy，则参考以下步骤进一步排查：
  1. 使用 ssh 命令，登录对应的 OBProxy 节点。
  2. 使用 cd 命令，进入 OBProxy 的日志目录。OBProxy 的日志存放在其安装目录的 /log 目录下。
  3. 执行以下命令，过滤出错误日志。
```
grep "错误文本" obproxy_error.log obproxy_error.log.xxx | grep "出错时间点"
```
  4. 根据过滤出的日志条目，找到出错的 SQL 所路由的 OBServer 节点。
  5. 再通过 ssh 命令，登录对应的 OBServer 节点进行排查。
- 否，不经过 OBProxy，则参考以下步骤进一步排查：
  1. 使用 ssh 命令，登录对应的 OBServer 节点。
  2. 进入日志所在目录。
    
    以下以 OceanBase 数据库的安装目录为 /home/admin/oceanbase 为例，日志的具体存放路径请以实际环境为主。
```
cd /home/admin/oceanbase/log
```
  3. 执行以下命令，过滤出错误日志。
```
grep "sending error" observer.log observer.log.xxx | grep "错误码'
```
  4. 根据过滤出的日志，获取到 trace_id，然后继续使用 trace_id 过滤日志。
```
grep "trace id" observer.log observer.log.xxx
```
  5. 根据日志提供的信息，结合相关错误提示信息等进行问题分析。
    
    更多日志相关的介绍，参见日志概述。如遇日志中信息不明确，请联系技术支持人员协助排查。

典型案例

普通业务租户的普通用户直连 OceanBase 数据库的 2881 端口时遇到报错 ERROR 1040 (08004): Too many connections。具体排查操作参见普通用户连接时遇到报错 ERROR 1040 (08004): Too many connections。

应用异常--错误信息中包含 OceanBase 错误码

流程介绍

通过复现问题进行问题排查

注意

排查程序配置的数据源信息

典型案例

相关文档