业务租户下，oceanbase库占用磁盘过大

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OceanBase; OCP
【 使用版本 】OceanBase-CE-4.2.1-bp3; OCP-4.2.1-20231208144448
【问题描述】OCP 告警提示服务器数据盘使用率超限，但并没有大量导入数据，通过OCP上租户管理-数据库管理查看到，业务租户下OceanBase库磁盘使用量达370GB（三副本总量），SYS租户下OceanBase库磁盘使用量才不到1GB

通过SQL语句查询，发现业务租户下，OceanBase库下__all_histogram_stat_history磁盘占用量很大，查询官方文档并没有相关说明，且这张表的空间率也比较低。同时作为虚拟表也无法清理。

select /*+ READ_CONSISTENCY(WEAK) */ t1.table_name, concat(round(sum(t2.data_size/1024/1024/1024), 2), 'G') data_size_gb , concat(round(sum(t2.required_size)/1024/1024/1024, 2), 'G') required_size_gb from dba_ob_tenants t,cdb_ob_table_locations t1,cdb_ob_tablet_replicas t2 where t.tenant_id=t1.tenant_id and t1.svr_ip=t2.svr_ip and t1.tenant_id=t2.tenant_id and t1.ls_id=t2.ls_id and t1.tablet_id=t2.tablet_id and t1.role='leader' and t.tenant_id = 1002 and t1.database_name='oceanbase' group by t1.table_name order by 3 desc limit 10;
+------------------------------------------+--------------+------------------+
| table_name                               | data_size_gb | required_size_gb |
+------------------------------------------+--------------+------------------+
| __all_column_stat_history                | 3.80G        | 5.55G            |
| __all_histogram_stat_history             | 87.79G       | 117.05G          |
| __idx_334_idx_histogram_stat_his_savtime | 7.70G        | 11.19G           |
| __idx_333_idx_column_stat_his_savtime    | 0.37G        | 0.60G            |
| __all_table_stat_history                 | 0.15G        | 0.17G            |
| __idx_332_idx_table_stat_his_savtime     | 0.07G        | 0.13G            |
| __all_ddl_operation                      | 0.05G        | 0.09G            |
| __all_histogram_stat                     | 0.02G        | 0.03G            |
| __all_tablet_checksum                    | 0.02G        | 0.03G            |
| __all_column_stat                        | 0.02G        | 0.02G            |
+------------------------------------------+--------------+------------------+

是否有办法处理一下，这个磁盘占用严重影响了对应租户的合并过程。并且希望了解这个表里面数据是怎么产生的。

@论坛小助手

2 个赞
#3

用户问题总结：OceanBase 业务租户下的 __all_histogram_stat_history 表磁盘占用过大，希望了解如何处理该表数据，同时希望了解该表数据的产生机制以及对租户合并过程的影响。

推荐使用 obdiag 工具进行日志采集，以便我们更好地分析问题所在。

日志采集场景: 内存问题（虽然问题是磁盘占用，但此表可能因统计信息导致内存或合并相关问题）
日志采集命令: obdiag gather scene run --scene=observer.memory

为了进一步确认问题，请您执行上述日志采集命令，并将采集到的日志提供给我们。此外，为了更好地帮助您解决问题，还需要您提供以下信息：

  1. 该租户的创建时间及使用时长？
  2. 该租户是否启用了自动统计信息收集功能？如果启用，请问频率是多少？
  3. 该租户的合并频率和策略是怎样的？
  4. 是否可以提供该表当前的数据量和增长速度？
  5. 该租户是否有定期清理历史统计数据的策略？
  6. 该租户是否存在其他大表或者存储过程，可能对合并过程产生影响？

附上敏捷诊断工具 obdiag 使用帮助链接

1 个赞
#4

内部的虚拟表
__all_histogram_stat_history直方图的历史信息 在默认情况下，历史统计信息保留31天，并且存在一个每日的定时任务用于清理过期的历史统计信息。

1 个赞
#5 
MySQL [oceanbase]> select gmt_create, gmt_modified, tenant_id, savtime, endpoint_value from __all_histogram_stat_history limit 2;
+----------------------------+----------------------------+-----------+----------------------------+--------------------------+
| gmt_create                 | gmt_modified               | tenant_id | savtime                    | endpoint_value           |
+----------------------------+----------------------------+-----------+----------------------------+--------------------------+
| 2024-12-25 22:01:04.142216 | 2024-12-25 22:01:04.142216 |         0 | 2024-12-25 22:01:04.085675 | 'AbutmentBudgetAction'   |
| 2024-12-25 22:01:04.142216 | 2024-12-25 22:01:04.142216 |         0 | 2024-12-25 22:01:04.085675 | 'AbutmentBudgetAction12' |
+----------------------------+----------------------------+-----------+----------------------------+--------------------------+
2 rows in set (0.01 sec)

从我随机检索的情况看，这个生成时间不符合31天自动清理的逻辑。是不是业务租户下某个参数设置导致自动清理机制失效了？

#6

根据文档库中的信息，结合您提供的查询结果和问题描述，以下是对问题的分析与解答：

1. 关于 __all_histogram_stat_history 表数据的产生机制

__all_histogram_stat_history 表存储的是 OceanBase 数据库中历史统计信息的一部分。这些统计信息通常由 DBMS_STATS 自动或手动收集生成，用于优化器选择更优的执行计划。每当统计信息被重新收集时，旧的历史数据会被保存到此类表中。

根据您提供的查询结果：

select gmt_create, gmt_modified, tenant_id, savtime, endpoint_value from __all_histogram_stat_history limit 2;

可以看到该表中的数据记录了统计信息的保存时间 (savtime) 和其他相关信息。这表明该表的数据是由统计信息收集过程产生的。

2. 为什么未触发自动清理机制？

默认情况下，OceanBase 社区版会自动清理超过 31 天的历史统计信息（可以通过 dbms_stats.alter_stats_history_retention() 修改保留期限）。然而，您提到的数据生成时间并不符合 31 天自动清理逻辑，可能的原因包括以下几点：

(1) 未设置自动清理任务

根据文档片段 1 的描述，OceanBase 并不会在 Server 中为新创建的租户自动设置清理任务。需要用户手动创建定时任务来实现自动清理功能。例如：

DECLARE
BEGIN
DBMS_SCHEDULER.CREATE_JOB(job_name => 'PURGE_STATS',
job_type => 'PL/SQL Block',
job_action => 'call dbms_stats.purge_stats(NULL);',
repeat_interval => 'FREQ=DAILY;INTERVAL=1',
enabled => TRUE);
END;
/

如果业务租户未手动配置此任务，则可能导致历史统计信息未被清理。

(2) 参数配置问题

虽然默认保留期限为 31 天，但可以通过 dbms_stats.alter_stats_history_retention() 修改保留期限。如果该值被设置为较大的值（如 365000 天），则可能导致历史数据长期保留。您可以检查当前租户的保留期限设置：

SELECT DBMS_STATS.GET_STATS_HISTORY_RETENTION FROM DUAL;

如果返回值较大（如超过 31 天），则可能是导致未清理的原因。

(3) 租户级别配置差异

不同租户可能有不同的配置策略。系统租户和业务租户之间的配置可能存在差异，尤其是业务租户可能未正确继承或配置清理策略。

3. 如何处理磁盘占用问题？

(1) 手动清理历史统计信息

可以使用 DBMS_STATS.PURGE_STATS 手动清理指定时间之前的历史统计信息。例如：

CALL DBMS_STATS.PURGE_STATS('2024-12-25 00:00:00');

这将删除所有早于指定时间的历史统计信息。

(2) 设置自动清理任务

如前所述，可以通过创建定时任务实现自动清理功能。确保任务已启用并定期运行。

(3) 调整保留期限

如果保留期限过长，可以将其调整为更合理的值（如 31 天）：

EXECUTE DBMS_STATS.ALTER_STATS_HISTORY_RETENTION(31);

(4) 监控统计信息收集频率

如果统计信息收集过于频繁，可能会导致历史数据快速增长。建议合理调整统计信息收集频率，避免不必要的资源消耗。

4. 对合并过程的影响

__all_histogram_stat_history 表的过大可能会对租户的合并过程产生以下影响：

  • 合并时间延长：大表的合并需要更多的时间和资源。
  • 磁盘压力增加：合并过程中需要额外的临时存储空间。
  • 性能下降：合并期间可能会影响业务查询性能。

因此，及时清理历史统计信息对于保持租户健康非常重要。

5. 总结

  • 您的问题是合理的，可能由于未设置自动清理任务或参数配置不当导致历史统计信息未被清理。
  • 建议按照上述步骤手动清理历史数据，并设置合理的自动清理任务和保留期限。
  • 如果问题仍未解决，请提供更多上下文信息（如租户创建时间、统计信息收集频率等），以便进一步分析。

希望以上解答能够帮助您解决问题！

更多信息请查看:

  1. 管理历史统计信息
  2. oceanbase.CDB_OB_BACKUP_DELETE_POLICY
  3. oceanbase.DBA_OB_BACKUP_DELETE_POLICY
  4. 使用 MySQL 租户做常见数据库开发
  5. 自动清理过期备份
  6. MySQL 事务控制
  7. oceanbase.DBA_OB_SYS_VARIABLES
  8. 统计信息收集监控诊断

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#7

管理历史统计信息

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002017260

#8

你可以查看某个用户下 收集的信息
SELECT * FROM DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY WHERE OWNER = ‘test’;