数据库在运行期间经常会有各种异常情况出现，比如应用程序错误、数据库连接错误、数据库权限问题、数据库资源问题、网络问题等。在这所有的情况中，有一种就是应用异常，但是错误信息不包含 OB 的错误码，这类问题一般较难判断问题与 OB 的相关性从而导致排查方向不明确。
为了帮助大家快速定位这种场景下的问题根源并高效解决，这里总结了一套清晰、实用的 应用异常且报错信息不包含 OB 错误码报错排查流程。这套流程提供明确的操作步骤，旨在提升问题处理效率，尽可能降低对业务的影响，为日常运维工作提供有力的支持。
下图是应用执行报错且错误信息不包含 OB 错误码问题排查流程图。
流程介绍
当遇到应用执行异常且报错信息不包含 OB 错误码信息的场景，可以按照该流程进行问题排查。
分析应用程序侧报错逻辑，判断是否为断链异常问题。
- 是，则参见应用断链异常问题排查进行处理。
- 否，判断是否可以复现。
* 是，通过程序代码调试、网络抓包分析比如tcpdump等手段分析程序代码报错原因，从而确认问题触发逻辑明确分析方向。
* 否，尝试通过现有信息结合程序自身逻辑推测报错原因，从而确认问题触发逻辑明确分析方向。
以上为应用异常且不包含 OB 错误码的问题排查流程，希望能为日常运维工作提供有力的支持。
典型案例
不区分模式
-
数据库连接异常断开，请参见 SQL 执行报错连接已断开。
-
用户在一个分布式集群环境里面配置有多个 IP 地址，想通过多个 IP 连接登录集群，请参见 OBClient 客户端工具如何支持多 IP 连接登录。
-
OceanBase 数据库在进行业务 commit 时遇到如下异常报错：
Transaction resolution unknown，请参见 应用报错：Transaction resolution unknown。 -
应用程序端反馈在进行大数据量导入时 应用日志报错 Connection is closed & Connection reset。请参见 OBProxy 由于内存使用超限导致应用报错：Connection reset。
-
应用 SQL 偶发性执行耗时长。请参见 应用 SQL 在 OceanBase 侧执行耗时抖动。
-
业务在测试环境执行时，从应用侧观测到 SQL 平均耗时 2ms，而在生产环境执行时耗时变成了 30~40ms，但数据库内的 SQL 耗时并没有增长。请参见 应用侧 SQL 执行耗时远高于数据库内的问题。
-
OceanBase 数据库 socket 级故障检测，请参见 如何配置 OceanBase 数据库的 socket 级故障检测超时时间。
MySQL 模式
- 客户端在执行 SQL 时直接报错
Lost connection to MySQL server during query。通常，此类报错是因为服务器端出现异常导致，导致链接中断。请参见 客户端报错 Lost connection to MySQL server during query 的几种原因。
Oracle 模式
-
Oracle 模式下，应用使用 setFetchSize(Integer.MIN_VALUE) 报错
invalid fetch size。请参见 Oracle 模式应用报错 invalid fetch size。 -
OceanBase Connecotr/JDBC 驱动报错。请参见 SQL 报错时区无法解析。
-
在应用端通过 JDBC 连接 OceanBase 数据库超时，请参见 通过 JDBC 连接 OceanBase 数据库，获取连接超时。
-
使用 JDBC 时，应用侧报错 multi stmts sql while OB_CLIENT_MULTI_STATEMENTS not enabled。请参见 应用侧报错 multi stmts sql while OB_CLIENT_MULTI_STATEMENTS not enabled。
-
系统从 Oracle 切换到 OceanBase Oracle 租户后，使用 JBoss 部署的 JDBC 应用出现连接数不足的问题。请参见 JBoss 部署的 JDBC 应用出现连接数不足的问题。