数据库在运行期间经常会有各种异常情况出现，比如应用程序错误、数据库连接错误、数据库权限问题、数据库资源问题、网络问题等。在这所有的情况中，有一种就是应用异常，但是错误信息包含 OB 的错误码。
为了帮助大家快速定位这种场景下的问题根源并高效解决，这里总结了一套清晰、实用的应用异常且报错信息包含 OB 错误码报错排查流程。这套流程提供明确的操作步骤，旨在提升问题处理效率，尽可能降低对业务的影响，为日常运维工作提供有力的支持。
下图是应用执行报错且错误信息包含 OB 错误码问题排查流程图。
流程介绍
当遇到应用执行异常且报错信息包含 OB 错误码信息的场景，可以按照该流程进行问题排查。
首先要判断是否可以用 obclient 连接数据库手动复现问题，是的话，可以通过连接后问题复现进行排查；否的话，需要排查程序配置的数据源信息。
- 复现问题进行问题排查
-
使用 obclient 通过 2881 连接 OB 集群。
-
手动执行 SQL 复现问题场景。
-
获取 trace_id。
- Oracle 租户，执行
select last_trace_id() from dual; - MySQL 租户，执行
select last_trace_id;
- Oracle 租户，执行
-
获取实际执行 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';
- V2.x 版本和 V3.x 版本，执行
-
使用
ssh命令登录到对应的主机， -
使用
cd命令进入对应的日志文件夹。命令如下：cd /home/admin/oceanbase/log。 -
执行如下命令过滤日志中相关信息。
grep "${trace_id}" observer.loggrep "${trace_id}" observer.log.xxxx
-
根据日志中信息，结合日志分析相关问题。更多日志信息，请参考日志概述。如遇日志中信息不明确，可以联系技术支持人员一起排查。
- 排查程序配置的数据源信息，详细信息如果有需要可以咨询相关使用方。
- 根据数据源明确访问链路。
- 明确访问链路包含如下信息的数量和地址。
- obproxy 的数量与地址信息
- OBServer主机的数量与地址信息
- 判断是否经过 obproxy。
-
是。
-
通过 ssh 登录对应的 obproxy 节点。
-
使用 cd 命令进入 obproxy 的日志目录
-
执行如下命令，过滤出错误日志。
grep "错误文本" obproxy_error.log obproxy_error.log.xxx | grep "出错时间点' -
根据过滤出的日志条目，找出出错的 SQL 所路由的 OB 节点。
然后通过 ssh 登录对应的的 OB 节点进行排查。
-
-
否。
-
通过 ssh 登录对应的的 OB 节点。
-
进入日志目录，命令如下。
cd /home/admin/oceanbase/log -
执行如下命令，过滤出错误日志。
grep "sending error" observer.log observer.log.xxx | grep "错误码' -
通过过滤出的日志，获取 trace_id，然后继续使用 trace_id 过滤日志。
grep "trace id" observer.log observer.log.xxx -
根据日志中信息，结合日志分析相关问题。更多日志信息，请参考日志概述。如遇日志中信息不明确，可以联系技术支持人员一起排查。
-
-
以上为应用异常且包含 OB 错误码的问题排查流程，希望能为日常运维工作提供有力的支持。
典型案例
不区分模式
- MyBatis 使用 OceanBase Connector/J V2.4.10 版本驱动，连接 OceanBase 数据库执行 SQL 报错
-5930 maximum open cursors exceeded。请参见 应用使用 OceanBase Connector/J V2.x 版本驱动执行 SQL 报错 maximum open cursors exceeded 的原因和解决方法。 - OBServer 出现 force_disconnect 告警。请参见 OBServer 出现 force_disconnect 告警的触发逻辑和原因。
- OceanBase 集群出现 Failed to do check_ack_timeout 告警。请参见 OceanBase 集群出现 Failed to do check_ack_timeout 告警的原因。
- 普通业务租户的普通用户直连 OceanBase 数据库的 2881 端口时遇到报错
ERROR 1040 (08004): Too many connections。请参见 普通用户连接时遇到报错 ERROR 1040 (08004): Too many connections。 - 在业务频繁建连接断连接场景下，建连接总数达到一定量以后，发生建连接报错 4016。请参见 OceanBase 数据库 V4.x 版本中建连接报错 4016。
MySQL 模式
- 应用执行 insert 出现报错 00918。请参见 应用执行 insert 出现报错 00918。
Oracle 模式
- 通过 OceanBase 数据库中的
DBLink去访问大数据 LOB 类型时会遇到报错：ORA-00600: internal error code, arguments: -4007, Not supported feature or function。请参见 使用 DBLink 访问 LOB 类型时遇到报错：-4007, Not supported feature or function 的原因和解决方法。