【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
select * from oceanbase.DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY；
这个视图从什么时间开始统计？
where加上条件列table_name，好多表查出来信息是空的。
自动收集收集的是统计信息缺失或者统计信息过期的表，按照增量收集的方式进行收集，也就是只收集数据变化的分区，而不用重新收集整个表的统计信息，过期标准是看针对每个分区来说增量的DML info变化是否满足过期的阈值（默认：10%，即单个分区距离上一次收集期间增删改的总量不超过当前表数据量的10%）。
步骤一，按照租户类别使用如下SQL查询进行检查，主要检查最近一天内的所有租户自动收集是否有正常调度，如果调度正常，跳转步骤二，否则请先排查自动收集任务调度的问题： [自动统计收集任务调度问题排查]
– sys租户，查询非空则说明有租户调度异常（推荐）
SELECT tenant_id AS failed_scheduler_tenant_id
FROM oceanbase.__all_tenant t
WHERE NOT EXISTS(SELECT 1
FROM oceanbase.__all_virtual_task_opt_stat_gather_history h
WHERE TYPE = 1
AND start_time > date_sub(now(), interval 1 day)
AND h.tenant_id = t.tenant_id);
步骤二，按照租户类别使用如下SQL查询进行检查，获取过去一天的自动收集是表收集失败列表，如果为空则说明自动收集正常
– 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;
步骤1和步骤2结果都为空。
昨天提问时的表，今天看自动收集成功了。
另外好多表还是有同样的问题，不会是要有select以后晚上才会自动收集吧？看晚上的自动任务会不会把这个表收集
这些表的数据是离线导入、oms导入的么？还是业务的dml操作？
oms全量导入后，ogg同步。业务有查询操作。
要特定的时间窗口收集，并不是导数后dml info过期数据超过10%就会收集 oms 迁移完数据或者ogg同步数据 业务不是高峰期的话 自己手动做一次统计信息收集
晚上的自动任务没有正常收集这个表
展示数据库中所有表的自上次在该表上收集统计信息以来的修改信息。
手动收集表的统计信息以后，这个表里面的信息也没有变化。
查询这个视图的信息导致认为表变化量很多但是没有自动收集。
1、你查询一下 自动收集统计信息的历史任务 是否有执行
2、手动收集统计信息的命令发一下
3、你展示一下查询的这个表的信息 看看是什么信息
4、是不是数据量多大 执行任务是不是还没有结束？这个查询一下
1、select * from oceanbase.DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY；
2、CALL dbms_stats.gather_table_stats(‘db’, ‘test’, granularity=>‘ALL’, method_opt=>‘FOR ALL COLUMNS SIZE auto’,degree=>8);
3、select /*+ query_timeout(100000000000) */ * from oceanbase.DBA_TAB_MODIFICATIONS where table_name=‘xxx’;
select * from oceanbase.GV$DML_STATS where objn=1531175;
4、select * from oceanbase.GV$OB_OPT_STAT_GATHER_MONITOR;
Empty set (0.02 sec)
select count() from xxxx;
±---------+
| count() |
±---------+
| 20457931 |
±---------+
1 row in set (0.50 sec)
看着 其他的没啥问题 没有对比的查询 不好对比 可以用第二个查询 查的更详细
–MySQL业务租户查询 对比着查询 手动收集之前和之后 有数据变化的一段时间了 没有运行自动收集统计信息之前的这段时间
1、select /*+ query_timeout(100000000000) */ * from oceanbase.DBA_TAB_MODIFICATIONS where table_name=‘xxx’;
2、通过如下查询，按照租户类型再业务租户进行查询统计信息缺失或者过期的表，并且按照数据量排序：
– MySQL业务租户查询
SELECT v2.database_name,
v2.table_name,
Sum(inserts - deletes) row_cnt
FROM oceanbase.dba_tab_modifications v1,
(SELECT DISTINCT database_name AS DATABASE_NAME,
table_name AS table_name
FROM oceanbase.dba_ob_table_stat_stale_info
WHERE is_stale = ‘YES’
AND database_name != ‘oceanbase’) v2
WHERE v1.table_name = v2.table_name
GROUP BY v2.database_name,
v2.table_name
ORDER BY row_cnt;
