截断具有许多子分区的表需要很长时间

Posted 2023-02-24

【中文标题】截断具有许多子分区的表需要很长时间

【英文标题】：Truncating a table with many subpartitions taking too long time

【发布时间】：2021-12-23 21:03:33

【问题描述】：

我们有一项工作，每晚从源数据库加载一些表到目标数据库，其中许多是按范围或列表分区的。在加载一个表之前，我们首先将其截断，由于某种原因，这个过程对于特定表来说需要很长时间。

例如，TABLE A 有 6200 万行，并已按列表（BRANCH_CODE 列）进行分区。分区数为 213。截断此表需要 20 秒。

TABLE B 有 1700 万行，由DAY 列进行范围分区，间隔为月，每个分区按列表（BRANCH_CODE 列）有 213 个子分区。所以在本例中，分区数为 60，子分区数为 12780。截断此表需要 15 分钟。

是long truncate process 分区太多的原因吗？或者我们可能错过了一些表格规范，或者我们应该为表格设置特定的存储参数？

【问题讨论】：

您是否测试过 insert to temp、drop purge、create ？

你会截断整个表格吗？或者你截断分区或子分区？它看起来像一个奇怪的设计。当您分区或子分区时，您可以独立处理这些段。如果要截断整个表，为什么会有这么多分区和子分区？

@AliFidanli ，您的意思是通过将表内容插入另一个没有分区的临时表，删除目标表然后创建为选择来测试它吗？

如果是这种情况，并且查询正在使用分区修剪，那么设计是有意义的，而不是人口。也许只截断上个月的分区会好很多，一种增量的方法

@Sherzodbek，这正是我的意思。您始终可以使用 alter table truncate partition 语句的子句更新索引。阅读有关它的文档

【参考方案1】：

手动收集固定对象和数据字典统计信息可能会提高支持截断 12,780 个对象所需的元数据查询的性能：

begin
    dbms_stats.gather_fixed_objects_stats;
    dbms_stats.gather_dictionary_stats;
end;
/

上述命令可能需要几分钟才能完成，但您通常只需在系统中的对象数量发生重大变化后运行一次。添加 12,780 个子分区可能会导致类似这样的奇怪问题。 （在调查这些问题时，您可能还想检查与如此多的子分区相关的空间开销。创建如此多的分区时很容易浪费许多 GB 的空间。）