获取诊断信息 - 数据库代理 V4.3.2

获取诊断信息

更新时间：2026-04-14 17:41:09

本文介绍两种获取诊断信息的方法，您可通过如下任一方法获取诊断信息。

命令行语句

您可通过 explain route <your_sql>; 命令获取 SQL 语句的路由状态信息，该命令会展示详细的诊断信息。<your_sql> 语句将会在 ODP 内部进行处理，执行正常的 ODP 转发流程，但不会真正转发给 OBServer 节点。

explain route 命令不支持诊断如下命令字。

COM_STMT_PREPARE
COM_STMT_PREPARE_EXECUTE
COM_STMT_CLOSE
COM_STMT_RESET
文本 Prepare（语法：PREPARE statement_name FROM preparable_SQL_statement; ）
文本 Prepare drop（语法：{DEALLOCATE | DROP} PREPARE stmt_name;）
ODP 内部命令

示例

查询一个不存在的表，SQL 语句为 SELECT * FROM test.list_sub_parts_my_01 WHERE c3='1999-09-09' AND c1=mod(1999,1000) AND c2='tiger0'。

obclient> EXPLAIN ROUTE SELECT * FROM test.list_sub_parts_my_01 WHERE c3='1999-09-09' AND c1=mod(1999,1000) AND c2='tiger0'\G

输出如下。

*************************** 1. row ***************************
Route Plan:
Trans First Query:"SELECT * FROM test.list_sub_parts_my_01"
Trans Current Query:"EXPLAIN ROUTE SELECT * FROM test.list_sub_parts_my_01 WHERE c3='1999-09-09' AND c1=mod(1999,1000) AND c2='tiger0'"
Route Prompts
-----------------
> ROUTE_INFO
  [INFO] Will do table partition location lookup to decide which OBServer to route to
> TABLE_ENTRY_LOOKUP_DONE
  [INFO] No available entry because table entry lookup failed
> ROUTE_INFO
  [INFO] Will route to cached connected server(10.10.10.1:4001)

Route Plan
-----------------
> SQL_PARSE:{cmd:"COM_QUERY", table:"list_sub_parts_my_01"}
> ROUTE_INFO:{route_info_type:"USE_PARTITION_LOCATION_LOOKUP", in_transaction:true}
> LOCATION_CACHE_LOOKUP:{mode:"oceanbase"}
  > TABLE_ENTRY_LOOKUP_START:{}
    > FETCH_TABLE_RELATED_DATA:{table_entry:"partition information does not exist"}
  > TABLE_ENTRY_LOOKUP_DONE:{is_lookup_succ:true, entry_from_remote:false}
> ROUTE_INFO:{route_info_type:"USE_CACHED_SESSION", svr_addr:"10.10.10.1:4001", in_transaction:true}
> CONGESTION_CONTROL:{svr_addr:"10.10.10.1:4001"}

结果集说明如下。

Trans First Query：事务首条语句内容
Trans Current Query：事务当前语句内容
Route Prompts：路由提示，对某些路由过程中的步骤进行解释，分为 [INFO] 和 [WARN] 提示
- [INFO]：表示路由过程正常，会输出帮助您理解路由过程的一些信息。示例中 ROUTE_INFO 输出了 [INFO] 信息，通过阅读信息可以知道，本次请求将通过分区位置查询来决定路由至哪个 OBServer 节点
- [WARN]：表示路由过程中对应步骤出现异常，重点检查该步骤的信息输出
Route Plan：路由计划，展示 ODP 转发过程。其中 SQL_PARSE/ROUTE_INFO/LOCATION_CACHE_LOOKUP 为诊断点，诊断点之间存在同级或者父子关系，呈树状。详细信息可参见诊断点排查章节。

通过 Route Plan 中的 FETCH_TABLE_RELATED_DATA:{table_entry:"partition information does not exist"} 可以得知 ODP 查询该表的分区信息，但其信息不存在。

大多数时候通过 Route Prompts 输出信息就可以确认问题，如果不能则结合 Route Prompts 与 Route Plan 一起排查问题。

诊断日志

当 SQL 语句满足以下条件且配置项 route_diagnosis_level 不为 0 时，ODP 会将实际路由过程输出到 obproxy_diagnosis.log 日志中。

非 EXPLAIN ROUTE executable_sql; 语句
分区未命中（is_partition_hit = false）或者 route_diagnosis_level = 4

日志输出时，会根据当前语句所处的场景决定输出日志级别为 WARN 或 TRACE，具体场景如下。

输出 WARN 级别日志
- 分布式事务内路由语句
- 事务首条语句
输出 TRACE 级别日志
- 普通事务内事务路由语句
- 语句表名为空
- 语句超长（长度大于 request_buffer_length 配置项）
- 分区键计算失败

诊断日志支持的命令字/类型如下所示。

COM_QUERY
COM_STMT_PREPARE_EXECUTE
COM_STMT_PREPARE
COM_STMT_SEND_PIECE_DATA
COM_STMT_GET_PIECE_DATA
COM_STMT_FETCH
COM_STMT_SEND_LONG_DATA
非 ODP 内部命令

示例

在 obproxy_diagnosis.log 中找到想诊断的日志行，过滤关键字得到该行，然后替换该日志行内的 '/n' 为 '\n' 得到树状的诊断过程。

脚本命令：grep "some_key_word" obproxy_diagnosis.log | sed "s//n/\n/g"，示例如下。

$ grep "2023-08-17 16:56:46.521180" obproxy_diagnosis.log | sed "s/\/n/\n/g"

输出如下。

[2023-08-17 16:56:46.521180] [31792][Y0-00007F38DAAF34E0] [ROUTE]((*route_diagnosis=
Trans Current Query:"select * from test.range_sub_parts_my_01 where c1=22222 and c2=111111 and c3=abcd"
...
> PARTITION_ID_CALC_DONE
  [WARN] Fail to calculate first part idx may use route policy or cached server session

Route Plan
> SQL_PARSE:{cmd:"COM_QUERY", table:"range_sub_parts_my_01"}
> ROUTE_INFO:{route_info_type:"USE_PARTITION_LOCATION_LOOKUP"}
> LOCATION_CACHE_LOOKUP:{mode:"oceanbase"}
  > TABLE_ENTRY_LOOKUP_DONE:{table:"range_sub_parts_my_01", table_id:1099511677778, partition_num:16, table_type:"USER TABLE", entry_from_remote:false}
  > PARTITION_ID_CALC_START:{}
    > EXPR_PARSE:{col_val:[[0]["c1", "22222"], [1]["c2", "111111"], [2]["c3", ""]]}
    > RESOLVE_EXPR:{error:-4002, sub_part_range:"(111111,MIN ; 111111,MAX)"}
      > RESOLVE_TOKEN:{resolve:{"BIGINT":22222}, token_type:"TOKEN_INT_VAL", token:"22222"}
      > RESOLVE_TOKEN:{resolve:{"BIGINT":111111}, token_type:"TOKEN_INT_VAL", token:"111111"}
      > RESOLVE_TOKEN:{error:-4002, , token_type:"TOKEN_COLUMN", token:"abcd"}
  > PARTITION_ID_CALC_DONE:{error:-4002, partition_id:-1, level:2, partitions:"(p-1sp-1)"}
> ROUTE_POLICY:{replica:"10.10.10.1:50110", idc_type:"SAME_IDC", zone_type:"ReadWrite", role:"FOLLOWER", type:"FULL", chosen_route_type:"ROUTE_TYPE_NONPARTITION_UNMERGE_LOCAL", route_policy:"MERGE_IDC_ORDER_OPTIMIZED", trans_consistency:"STRONG", session_consistency:"STRONG"}
> CONGESTION_CONTROL:{svr_addr:"10.10.10.1:50110"}
> HANDLE_RESPONSE:{is_parititon_hit:"false", state:"CONNECTION_ALIVE"}
)

诊断过程如下。

通过 PARTITION_ID_CALC_DONE 下的 [WARN] Fail to calculate first part idx may use route policy or cached server session 可以知道计算一级分区 ID 失败，将会通过路由策略路由或者复用会话。
检查诊断点 PARTITION_ID_CALC_DONE 附近数据，发现 RESOLVE_TOKEN:{error:-4002, , token_type:"TOKEN_COLUMN", token:"abcd"}，由此得知 ODP 解析 c3=abcd 时出现解析错误。