自动统计信息收集报错问题

OceanBase 技术问题
#1

社区版 OceanBase 构建版本号：4.2.2.1-101000012024030709

查看表的统计信息收集任务，发现有很多报错，但是手动执行收集又能成功。

select * from oceanbase.DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY 
where owner in ('zabbix') and table_name in ('items')
order by start_time desc limit 10;

image
image1599×349 40.5 KB

最新一笔成功的是手动收集统计信息（参数取自报错的任务参数），命令如下：

CALL dbms_stats.gather_table_stats('zabbix', 'items', granularity=>'GLOBAL', method_opt=>'FOR ALL COLUMNS SIZE AUTO', DEGREE=>1, ESTIMATE_PERCENT=>100);

表 items 数据量很小，也就 250862 笔。

请问这个报错大家有什么排查思路吗？

#3

可能原因很多，分区表的多级统计信息收集，直方图，该表的业务sql可能处在高峰期当时。
可以查看 DBA_OB_TASK_OPT_STAT_GATHER_HISTORY 视图来获取具体的任务执行情况

1 个赞
#4

1、收集失败的表是一个数据量大表（行数超过上亿），长时间没收集成功，出现收集超时报错-4012。
针对大表的统计信息收集，其收集耗时的地方主要在三个地方：
1） 表数据量大，收集需要全表扫，耗时高；
2）直方图收集涉及复杂的计算，带来额外成本的耗时；
3）大分区表默认收集二级分区、一级分区、全表的统计信息和直方图，（ob422及其以上的版本已经优化）

  • 设置合适的默认收集并行度，需要注意的是设置并行度之后，需要调整相关的自动收集任务在业务低峰期进行
  • 设置默认列的直方图收集方式，考虑给数据分布均匀的列设置不收集直方图
  • 设置默认分区表的收集粒度，针对一些分区表，形如hash分区/key分区之类的，可以考虑只收集全局的统计信息，或者也可以设置分区推导全局的收集方式

2、租户中的表太多，大部分表都需要重新收集统计信息，但是收集窗口时间有限，导致未收集完成，该场景下需要考虑重新对该租户在业务低峰期 的时候手动收集一次。
3、非超时报错，其他错误码，请先在业务低峰期 对该表重新手动收集一次统计信息

#5

这个表好像只能看到收集失败的表数量，没有具体是哪些表活着失败的原因。。如果有字段能简单提示排查其实可能更方便

#6

视图 DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY 的粒度是表，能看到失败的表。而 DBA_OB_TASK_OPT_STAT_GATHER_HISTORY 的粒度是任务。每天自动收集统计信息是一个任务，所以看不到有效的信息。

image
image1446×512 48.1 KB

看统计信息收集任务作业，也没有到超时时间

select owner,job_name,job_action, start_date, repeat_interval,enabled, last_start_date, next_run_date,FAILURE_COUNT, max_run_duration,comments from OCEANBASE.DBA_SCHEDULER_JOBS	;

image
image1862×275 38.3 KB

原因不好查…

1 个赞
#7

基本上排查
1、租户调度是否异常
2、自动收集任务调度是否有问题
– sys租户，获取的所有租户信息，可以指定租户查询（推荐）
SELECT t_opt.tenant_id,
t_opt.task_id,
task_opt.start_time AS task_start_time,
task_opt.end_time AS task_end_time,
d.database_name,
t.table_name,
t_opt.table_id,
t_opt.ret_code,
t_opt.start_time,
t_opt.end_time,
t_opt.memory_used,
t_opt.stat_refresh_failed_list,
t_opt.properties
FROM (
SELECT tenant_id,
task_id,
start_time,
end_time,
table_count
FROM oceanbase.__all_virtual_task_opt_stat_gather_history
WHERE type = 1
– AND tenant_id = {tenant_id}
AND start_time > date_sub(Now(), interval 1 day)) task_opt
JOIN oceanbase.__all_virtual_table_opt_stat_gather_history t_opt
JOIN oceanbase.__all_virtual_table t
JOIN oceanbase.__all_virtual_database d
WHERE t_opt.ret_code != 0
AND task_opt.task_id = t_opt.task_id
AND task_opt.tenant_id = t_opt.tenant_id
AND t_opt.tenant_id = t.tenant_id
AND t_opt.table_id = t.table_id
AND t.tenant_id = d.tenant_id
AND t.database_id = d.database_id
AND t_opt.table_id > 200000;

3、如果租户调度没有问题基本上都是根据__all_virtual_table_opt_stat_gather_history的status的状态来判断是否有问题
例如：自动收集卡在超大表运维手段
使用如下SQL检查当前大表过去一段时间的收集情况，观察是否都是一个收集耗时长的过程，如果查询sys租户的 ret_code 字段非0表示收集失败，查询业务租户视图的 status 字段非 ‘SUCCESS’ 或者 NULL 表示收集失败
– sys租户
SELECT *
FROM oceanbase.__all_virtual_table_opt_stat_gather_history
WHERE table_id = {table_id}
ORDER BY start_time;

– MySQL业务租户
SELECT *
FROM oceanbase.dba_ob_table_opt_stat_gather_history
WHERE table_name = ‘{table_name}’
ORDER BY start_time;
4、确实没有特别细粒度的排查信息

1 个赞