一、通用排错总流程（标准步骤）
收集现象，缩小范围
报错完整文本、OB 错误码（‑xxxx）、ORA 错误码、发生时间点
影响范围：全部租户 / 单个租户？全部 SQL / 某一条 SQL？偶发必现？
访问链路：是否经过 OBProxy？应用直连 OBServer？
优先手动复现
使用 obclient 连接集群，手动执行报错 SQL，看能否复现：
bash
obclient -hxxx -P2881 -u用户名@租户名#集群名 -p
可复现：抓trace_id，查审计视图、节点日志
不可复现：应用侧问题、网络、OBProxy、偶发资源 / 锁 / 切主问题
获取 trace_id（定位 SQL 全链路日志，最重要）
执行完报错 SQL 立刻执行，否则 trace_id 会被覆盖
sql
– Oracle模式
select last_trace_id() from dual;
– MySQL模式
select last_trace_id;
通过 trace_id 去GV$OB_SQL_AUDIT找到该 SQL 实际执行的svr_ip（OBServer 节点 IP）。
定位对应节点，检索日志
登录svr_ip对应服务器，进入日志目录，用 trace_id 过滤日志。
区分问题域：应用 / OBProxy/OBServer/ 网络 / 资源 / 参数 / SQL 逻辑
工具辅助：obdiag 一键巡检、收集诊断信息
二、关键日志位置
OBServer 日志目录：$work_dir/log（示例：/home/admin/oceanbase/log）
表格
日志文件 用途
observer.log 主日志，全量运行日志
observer.log.wf 只打印 WARN/ERROR 级别，排错优先看这个
rootservice.log RS 根服务日志，集群元数据、合并、切主、副本管理
election.log 选主、副本仲裁日志
OBProxy 日志：obproxy安装目录/log/，obproxy_error.log看代理层报错。
检索日志示例：
bash
根据trace_id过滤全链路日志
grep “YB420B4043DA‑0005A535D6FAE81” observer.log
只看警告错误
grep “‑40” observer.log.wf
三、排错常用 SQL（系统视图）
1）SQL 审计，定位执行节点
sql
– Oracle租户
SELECT svr_ip,sql_id,trace_id,ret_code,error_msg,query_time FROM SYS.GV$OB_SQL_AUDIT
WHERE trace_id=‘你的trace_id’;
– MySQL租户
SELECT svr_ip,sql_id,trace_id,ret_code,error_msg,query_time FROM information_schema.GV$OB_SQL_AUDIT
WHERE trace_id=‘你的trace_id’;
2）租户内存资源（内存报错‑4013、‑4030）
sql
select * from __all_virtual_tenant_memstore_info;
3）事务、锁等待排查
sql
– 当前活跃事务
select * from __all_virtual_trans_stat;
– 锁等待事件
select * from DBA_OB_LOCKWAITS;
4）集群事件历史（切主、合并、节点上下线）
sql
select gmt_create,svr_ip,module,event from __all_server_event_history
order by gmt_create desc limit 100;
四、obdiag 诊断工具（官方排错神器）
bash
一键集群巡检，输出风险点和建议
obdiag check
根因自动分析，传入时间范围定位报错
obdiag rca --start-time “2026‑08‑31 10:00:00” --end-time “2026‑08‑31 10:10:00”
根据trace_id一键收集全节点相关日志
obdiag gather scene run --scene=observer.trace_collect_log --env trace_id=xxx
查看长事务
obdiag display scene run --scene=observer.long_transaction --env wait_time=60
五、高频错误码速查
表格
错误码 含义 排查方向
‑4013 内存不足 memstore 满 租户内存配置、转储合并、写入压力
‑4030 SQL 执行内存超限 调大ob_sql_work_area_percentage，优化大 SQL
‑4038 副本无主 / 切主 看 election.log、节点状态、网络、时钟偏差
‑6002 事务被 kill 轮转合并、切主、事务超时参数ob_trx_timeout
‑5131 锁等待超时 查DBA_OB_LOCKWAITS，长事务、行锁冲突
提示：OceanBase 错误码为负数，应用侧经常包装成 ORA‑xxxx，优先找原始负数错误码。
六、不同场景排错思路
场景 1：SQL 执行报错
拿完整报错 + trace_id；
GV$OB_SQL_AUDIT 看 ret_code、error_msg、svr_ip；
登录 svr_ip 节点 grep trace_id 看 observer.log；
看是否 SQL 语法、权限、资源、分布式执行 (PX) 问题。
场景 2：连接报错、断连
判断链路：应用→OBProxy→OBServer；
先看 OBProxy 日志，再看 observer 日志；
检查网络、防火墙、租户最大会话数、会话超时参数。
场景 3：集群 / 副本异常（无主、副本异常）
查询__all_virtual_meta_table看副本状态；
看 rootservice.log、election.log；
检查节点存活、时钟同步、网络连通性。
场景 4：偶发报错，无法复现
抓取报错时间窗口，用 obdiag rca 做时间窗口根因分析；
查__all_server_event_history确认是否发生切主、合并、节点抖动；
检查网络抖动、时钟漂移。
七、排错信息收集清单（提交问题时必备）
集群版本：select version();
完整报错文本、负数错误码、发生时间
trace_id（能拿到优先提供）
现象：必现 / 偶发，影响范围
obdiag 收集的诊断包，或关键节点 observer.log.wf 片段
小提示：线上优先使用obdiag，避免多节点手动一个个 grep 日志，大幅节省排错时间。
如果你手上有具体报错文本 / 错误码，我可以带你按这套流程一步步定位根因。