黑屏运维OceanBase数据库的常见案例

案例1：如何获取SQL语句对应的数据库日志信息

SQL不可重复执行时

1. 查看gv$ob_sql_audit视图，找到对应异常SQL语句，获取到TRACE_ID和svr_ip信息。

select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE, 
FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),'%Y-%m-%d %H:%i:%S') 
from GV$OB_SQL_AUDIT WHERE query_sql like '%关键字%' and REQUEST_TIME>='2025-07-21 14:34:00' limit 10;

2. 去对应svr_ip地址，通过TRACE_ID过滤日志信息。不同异常场景的问问题不一定都在observer.log日志中，例如执行备份命令失败，是可以在rootservice.log日志中解析出报错原因的。

[root@x.x.x.x ~]$ grep "YB420BA1CC68-000615A09D4CBDA0-0-0" observer.log*
[root@x.x.x.x ~]$ grep "YB420BA1CC68-000615A09D4CBDA0-0-0" rootservice.log*

3. 如果gv$ob_sql_audit信息淘汰或者数据库系统日志被刷掉或者系统日志等级太低时，可以按以下方式设置，等待SQL可执行复现问题时再按上述流程获取日志。

-- 设置日志等级，默认是WDIAG，基本够用
alter system set syslog_level='WDIAG';

--设置日志保留个数，需要注意磁盘空间是否能支撑日志数量
alter system set max_syslog_file_count='10';

SQL可以重复执行时

可以先按上述方式查看gv$ob_sql_audit排查进行。

1. 如果SQL执行立刻报错的，推荐使用系统租户获取trace_id。

登录系统租户，打开enable_rich_error_msg参数：

alter system set enable_rich_error_msg=true;

登录业务租户，执行报错SQL语句：

select count(*) from t2; 
ERROR 1146 (42502): Table 'test.t2' doesn't exist [xx.xx.xx.1:2882] [2024-04-13 20:10:20.292087] [YB420BA1CC68-000615A0A8EA5E38-0-0]

去xx.xx.xx.1节点过滤日志，如果最新日志无法过滤到，可以正则匹配多个日志进行过滤：

grep "YB420BA1CC68-000615A0A8EA5E38-0-0" rootservice.log
grep "YB420BA1CC68-000615A0A8EA5E38-0-0" observer.log

获取完日志信息后,关闭enable_rich_error_msg参数：

alter system set enable_rich_error_msg=false;

2. 如果执行的SQL语句返回成功，但SQL任务一直没完成时，推荐使用业务租户获取trace_id。例如执行开启归档时，归档状态未doing场景。

登录业务租户,设置ob_enable_show_trace变量：

SET ob_enable_show_trace='ON';

执行SQL语句，获取trace_id，此种方式只能返回trace_id，需要再通过gv$ob_sql_audit视图查到需要去哪个SVR_IP地址过滤日志。

-- 注意:需要在同一个会话中执行
select count(*) from test2;
select last_trace_id();
select * from oceanbase.gv$ob_sql_audit where trace_id='YBxxx';

按上述获取的SVR_IP和trace_id过滤日志，如果最新日志无法过滤到到，可以正则四配多个日志进行过滤。

grep "YBxxxxx" rootservice.log
grep "YBxxxxx" observer.log

案例2：如何收集SQL性能慢的信息

通过OBDIAG的一键诊断分析和全链路诊断中的Show Trace功能，或者通过查看gv$ob_sql_audit审计视图确认影响执行耗时的等待事件。

获取sql plan monitor信息

获取SQL执行计划EXPLAIN EXTENDED，查看执行计划并分析，获取sql plan monitor信息。

1. 登录sys租户设置sql_plan_monitor参数。

--确认sql_plan_monitor已经打开
show parameters like 'enable_sql_audit';

--如果enable_sql_audit=False则将其打开
alter system set enable_sql_audit=true;

2. 登录业务租户，获取sql的执行计划。

EXPLAIN EXTENDED sql语句;

3. 设置临时trace获取。

SET ob_enable_show_trace='ON';

4. 再次执行需要采集的sql语句。

5. 获取上一步执行的sql的trace_id信息。

select last_trace_id();

6. 临时关闭plan monitor数据，防止信息被覆盖。

alter system set enable_sql_audit = false;

7. 获取plan monitor的sql，将xxxx替换为第5步返回的trace_id，以获取每个算子的吐行信息。

select plan_line_id, plan_operation, sum(output_rows), sum(STARTS) rescan, 
min(first_refresh_time) open_time, max(last_refresh_time) close_time,
min(first_change_time) first_row_time, max(last_change_time) last_row_eof_time, count(1) 
from oceanbase.gv$sql_plan_monitor where trace_id ='xxxxx' group by
plan_line_id, plan_operation order by plan_line_id;

8. 恢复sql audit参数。

alter system set enable_sql_audit = true;

DDL执行不返回问题排查

DDL执行不返回的时候，怎么去排查？是正在执行还是执行卡住呢？涉及模块比较多，例如RS调度异常、锁冲突、PRC、业务压力大等。

获取当前正在执行的DDL信息：

select tenant_id,gmt_create,ddl_type,status,task_id,parent_task_id,object_id,
target_object_id,execution_id,trace_id,unhex(ddl_stmt_str) 
from __all_virtual_ddl_task_status;

如果获取不到任何信息，大概率是在RS调度阶段就已经异常了。

查看trace_id过滤rootservice.log日志：

select * from gv$ob_sql_audit where query_sql like '%DDL语句关键字%';

案例3：如何排查数据库初始化失败问题

不管OBD或OCP部署的数据库，初始化阶段失败需要通过observer.log日志排查问题原因，注意：初始化只能执行一次。

查看初始化阶段日志难点：

1. 初始化阶段日志被覆盖
2. 日志太多，找不到失败日志信息
3. 日志等级设置不正确，关键信息未打印

🐘 解决方式：

1. 设置系统日志保留个数

max_syslog_file_count设置多一点，需要注意系统日志占用空间问题。

2. 寻找关键字

除了查看ERROR比较明显的日志报错等级，还可以找初始化阶段ERROR的关键字Unexpected internal error happen,please checkout the internal errcode或者数据库启动时日志打印信息beginserver limit report。

3. 设置系统日志等级

syslog_level设置为WDIAG等级（默认）。

案例4：数据库升级失败如何排查日志

不管OBD或OCP升级数据库，升级都是调用数据库的升级脚本进行的，部分升级失败是无法单独通过这2个工具的日志确认问题原因的。需要关注以下这4个
数据库升级日志。

upgrade_checker.py        --->> upgrade_checker.log
upgrade_pre.py            --->> upgrade_pre.log
upgrade_health_checker.py --->> upgrade_cluster_health_checker.log
upgrade_post.py           --->> upgrade_post.log

⭐️ 注意:

• OBD执行升级数据库命令时，升级日志位于当前目录下。
• OCP执行升级数据库操作时，升级日志位于/tmp下，文件格式：版本信息/upgrade_*_{时间}.log，例如：/tmp/4.2.1.2-102000042023120514_upgrade_post_20240411101214.log。
• OBD执行升级数据库命令失败后，可以重复执行升级命令。
• OCP执行升级数据库操作步骤中失败后，不能直接跳过任务。

说明：日志格式问题后续会统一。OCP升级失败关键步骤后续会进行防御。

案例5：OBServer节点core掉后如何收集堆栈

OBServer遇到严重异常故障可能会宕掉产生Core文件，通常定位此类问题是需要OceanBase研发进行定位确认的，需要提供一些日志和堆栈信息。

Core文件配置信息：

grep "kernel.core_pattern" /etc/sysctl.conf
kernel.core_pattern = /obdata/data/core-%e-%p-%t

如果未配置，默认会在OceanBase数据库的home_path路径下生成core.${ob_pid}的文件。

可以通过ulimit -a或者ulimit -c查看当前资源的限制，如果设置为0或者很小则会在发生节点core时无法生产core文件的情况。

1. 日志关键字：

$ grep "CRASH ERROR" observer.log
CRASH ERROR!!! sig=6, sig_code=-6, sig_addr=3eb0000dbb, timestamp=17128228099270879, tid=4466, 
tname=ReplayEngine12, trace_id=0-0, extra_info=((null)), 
lbt=0x9af40d8 0x9ae4978 0x7f74fdbdd62f 0x7f74fd42a377 0x7f74fd42ba67 0x9a28638 0x873cffa 0x8dd491f 
0x8dd309b 0x8e6f22e 0x8b4e29c 0x8b4ac4b 0x8b48b04 0x9a69028 0x3426f0e 0x2cc7671 
0x985e884 0x985d271 0x9859d2e

2. 打印堆栈：

addr2line-pCfe ./bin/observer 0x9af40d8 0x9ae4978 0x7f74fdbdd62f 0x7f74fd42a377 0x7f74fd42ba67 0x9a28638 \
0x873cffa 0x8dd491f 0x8dd309b 0x8e6f22e 0x8b4e29c 0x8b4ac4b 0x8b48b04 0x9a69028 \
0x3426f0e 0x2cc7671 0x985e884 0x985d271 0x9859d2e

3. 应急处理:

• 在收集或备份完所需排查分析信息后，可以尝试手动重新拉起observer服务进程，观察是否恢复正常。
• 如果出现频繁core无法通过重启恢复，在集群可用情况下可以考虑替换节点、或者增大永久下线时间来防止节点被踢出集群。
• 如果集群不可用，可以考虑通过数据备份文件进行数据恢复或者切换物理备库恢复业务。

References
【1】https://www.oceanbase.com/docs/oceanbase-database-cn
【2】https://www.oceanbase.com/docs/obd-cn
【3】https://www.oceanbase.com/docs/ocp
【4】https://www.oceanbase.com/docs/ob-operator-doc
【5】https://www.oceanbase.com/docs/obdiag-cn