如何快速清理系统表的脏数据?

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

通过SQL语句查询,发现业务租户下,OceanBase库下__all_histogram_stat_history磁盘占用量很大

MySQL [oceanbase]> 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                | 4.45G        | 6.25G            |
| __all_histogram_stat_history             | 131.03G      | 171.50G          |
| __idx_334_idx_histogram_stat_his_savtime | 10.59G       | 15.33G           |
| __idx_333_idx_column_stat_his_savtime    | 0.42G        | 0.67G            |
| __all_ddl_operation                      | 0.05G        | 0.09G            |
| __all_tablet_checksum                    | 0.02G        | 0.04G            |
| __all_table_history                      | 0.02G        | 0.03G            |
| __all_histogram_stat                     | 0.02G        | 0.03G            |
| __all_column_history                     | 0.01G        | 0.02G            |
| __all_column_stat                        | 0.02G        | 0.02G            |
+------------------------------------------+--------------+------------------+
10 rows in set (1 min 46.66 sec)

在社区官方老师的支持下,排查到原因是自动调度的清理任务超时导致数据一直在累积,并且通过sys租户 alter system change tenant 到问题租户下,按天进行清理,但是delete语句的执行时间特别长,经过一夜的循环发起的清理任务,也没有很明显的效果。
对系统表执行truncate也显示权限报错

MySQL [oceanbase]> select /*+ parallel(64) QUERY_TIMEOUT(1000000000) */count(*) from __all_histogram_stat_history;
+------------+
| count(*)   |
+------------+
| 5310823486 |
+------------+

delete from oceanbase.__all_histogram_stat_history where savtime >= '2025-02-01 00:00:00' and savtime <= '2025-03-01 00:00:00';
.....

MySQL [oceanbase]> select /*+ parallel(64) QUERY_TIMEOUT(1000000000) */count(*) from __all_histogram_stat_history;
+------------+
| count(*)   |
+------------+
| 5183727294 |
+------------+
1 row in set (3 min 48.01 sec)

因此想再次请教一下社区的老师们,是否有什么快速清理系统表的办法?
[@论坛小助手]

1 个赞

根因分析场景: [无适用的根因分析场景]
日志采集场景: 日志归档问题
日志采集命令: obdiag gather scene run --scene=observer.log_archive

为了更好地帮助您解决系统表 __all_histogram_stat_history 数据量过大以及清理任务执行缓慢的问题,建议使用 obdiag 工具进行日志采集,并将采集到的日志提供给我们以便确认问题所在。上述命令可以帮助我们收集与日志归档相关的诊断信息。

请您根据以下步骤操作并提供更多信息:

  1. 执行上述 obdiag gather scene run --scene=observer.log_archive 命令后,请上传生成的日志压缩包。
  2. 您是否尝试过通过其他方式(如 DDL 或者权限提升)来清理该系统表?如果尝试过,请描述具体的操作过程和遇到的错误信息。
  3. 当前 OceanBase 集群的版本号是多少?
  4. 清理任务执行缓慢的具体表现是什么?例如,执行时间从多少增加到了多少?是否有具体的 SQL 语句可以提供?
  5. 在执行 truncate 操作时,具体的错误提示是什么?是否可以提供完整的错误日志?

感谢您的配合!

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

1 个赞

这个得看看问问官方文档

系统表没有办法使用truncate删除 只能用delete删除 如果一天的量比较大 建议按小时删除 目前只能通过这个方法删除