OBKV-Table 常见问题诊断

OBKV-Table 应用结构

要诊断 OBKV-Table 的问题需要先了解 OBKV-Table 在业务上的使用结构，总的来说 OBKV-Table 的链路经过以下几层，出问题时需要逐一分析。

• 业务代码
• SDK
• OBProxy 适用于部署及使用了 ODP(OceanBase Database Proxy) 的情况(包括云上)
• OBKV-Table Client
• OBServer

诊断手段

OceanBase 数据库端提供的排查手段主要有三种，一个是监控，包括 OCP、ant_monitor 等，另一个是日志，包括 observer.log、election.log、obproxy.log 等，还有一个是内部表，例如 gv$sql_audit、__all_rootservice_event_history 等。

为了方便问题排查，在业务抛出问题时需要搞清楚 5 个重要值：集群名，问题时间，问题机器，错误码，server_trace_id。

查看日志

对于一个问题，最简单的排查方式是登录到问题 server 上，通过 grep server_trace_id 查找问题时间所对应的 OceanBase 数据库日志，根据找到的日志进行分析。

例如常见的超时问题，在日志中可以看到超过用户设置的超时时间（10s）后，处理线程主动退出。

上诉查询中，有机会可以看到用户的具体请求。以及该请求执行过程中的事件和耗时记录，其中 u 的单位为 us。

有时候日志信息并不直观，可以根据日志的指引打开代码进行分析。

查看 sql_audit

在查看 sql_audit 之前，需要先开启 sql_audit 功能, 可通过系统租户设置。

具体语句如下：

obclient> alter system set enable_sql_audit=true;
obclient> alter system set enable_perf_event=true;

如果问题发生的时间比较近，那么很有可能 sql_audit 中依然有问题请求的记录，可以根据 svr_ip 和 trace_id 捞出分析。sql_audit 表中记录了一条请求的各阶段执行时间，在性能分析时很有用。

对 gv$sql_audit 表进行统计查询，可以获取最近一段时间内请求的趋势。具体的统计查询 SQL 因问题而异。

• 根据 trace_id 查询 sql_audit 数据。

  obclient> select /*+query_timeout(10000000000000) parallel(16)*/ * from gv$sql_audit where trace_id=''\G;
  

• 查询某台机器热点分区

  obclient> select /*+query_timeout(10000000000000) parallel(16)*/ usec_to_time(request_time), db_name, regexp_substr(query_sql, 'table_name:\"(.*)(\", table_id)', 1, 1, 'c', 1) as table_name, regexp_substr(query_sql, 'partition_id:(.*)(, entity_type)', 1, 1, 'c', 1) as partition_id, count(*) as count, substr(query_sql, locate('table api', query_sql), 24) as operation_type from gv$sql_audit where svr_ip='xxx.xxx.xxx.xxx' and query_sql like 'table api%' and elapsed_time>50000 group by db_name, table_name, partition_id order by count desc;
  

• 统计大查询数量及分布。

  obclient> select /*+query_timeout(100000000000) parallel(16)*/ usec_to_time(request_time), svr_ip, sum(case when elapsed_time > 50000 then 1 else 0 end) as long_req_count from gv$sql_audit where query_sql like 'table api%' and tenant_id=1011 group by svr_ip order by long_req_count desc;
  

• 统计各机器上的热点操作类型。

  obclient> select /*+query_timeout(10000000000000) parallel(16)*/ svr_ip, substr(query_sql, locate('table api', query_sql), 24) as op, count(*) as count from gv$sql_audit where query_sql like 'table api:%' and svr_ip='11.189.5.47' group by svr_ip, op order by count desc limit 20;
  

查看系统状态

1. 查看内存占用。

   obclient> select current_time(), tenant_id, svr_ip, sum(hold/1024/1024/1024) as hold_gb, max(hold/1024/1024/1024) as max_mod_gb, sum(case mod_name when "TABLE_PROC" then hold else 0 end)/1024/1024/1024 as table_api_gb from __all_virtual_memory_info where tenant_id=500 group by svr_ip order by hold_gb desc limit 30;
   

2. 诊断各模块内存占用。

   obclient> select  current_time(), tenant_id, svr_ip,  sum(hold)/1024/1024/1024 as hold_gb,  max(hold)/1024/1024/1024 as max_mod_gb, sum(case when mod_id >= 725 and mod_id <= 735 then hold else 0 end)/1024/1024/1024 as table_api_gb, sum(case when mod_name='TABLE_PROC' then hold else 0 end)/1024/1024/1024 as table_proc_gb, sum(case when mod_name='TABLE_STREAM_QUERY' then hold else 0 end)/1024/1024/1024 as query_gb, sum(case when mod_name='TABLE_QUERY_RESULT' then hold else 0 end)/1024/1024/1024 as query_result_gb, sum(case when mod_name='TABLE_ENTITY' then hold else 0 end)/1024/1024/1024 as entity_gb from __all_virtual_memory_info where tenant_id=500 group by svr_ip order by hold_gb desc limit 30;
   

查看系统事件

可以通过 __all_rootservice_event_history 表指定时间范围查看系统当时在执行的事件，通常关注转储、合并、迁移、切主等事件，并与问题时间和问题机器比对。

1. 执行以下命令查询合并事件。

   obclient> select * from __all_rootservice_event_history where gmt_create > '2019-10-31' and event in ('merging', 'idle') and module = "daily_merge" limit 100;
   

查看 table_api 热点请求

obclient> select /*+query_timeout(1000000000), parallel(16)*/ svr_ip, min(REQUEST_TIME), max(REQUEST_TIME), count(1), (max(REQUEST_TIME)-min(REQUEST_TIME))/1000000, 1000000 *count(1)/(max(REQUEST_TIME)-min(REQUEST_TIME)), substr(query_sql, 1, 30) from gv$sql_audit where query_sql like 'table api: %' and svr_ip='%'  group by svr_ip, substr(query_sql, 1, 30) order by count(1) desc;

信息不全时如何处理

有些错误可能 OBServer 节点没有回包，所以没有错误码和 server_trace_id，这时只能观察集群和问题机器进行合理猜测，然后通过日志或内部表进行验证。严重错误时，可以先查看有没有 ERROR 日志。

适用版本

OceanBase 数据库 V2.x、V3.x 版本。