我有几个大型 SQL Server 表,其中当前分区函数不会扩展到本月之后,并且在最终分区包含数据之前将分区函数拆分为新日期范围的过程未按预期运行。
所有这些表都有聚集列存储索引。当该索引就位时,如果您要拆分的分区有数据,则无法拆分分区函数范围。
我的策略是从每个使用分区函数的表中删除聚集列存储索引,然后更新分区方案并根据需要拆分分区函数范围,然后重建聚集列存储索引。
它看起来像这样:
USE [Database]
GO
DROP INDEX [reporting_ClaimStatus2_cci] ON [reporting].[ClaimStatus]
GO
------------------------------------
ALTER PARTITION SCHEME [PS_RPT1_Date_Month_Right]
NEXT USED [FG_ClaimDetail_2023M12]
GO
ALTER PARTITION FUNCTION [PF_RPT1_Date_Month_Right]()
SPLIT RANGE ( N'2023-12-01T00:00:00.000')
GO
------------------------------------------------------------
CREATE CLUSTERED COLUMNSTORE INDEX [reporting_ClaimStatus2_cci]
ON [reporting].[ClaimStatus]
WITH (DROP_EXISTING = OFF, COMPRESSION_DELAY = 0)
GO
我最大的问题是,我不知道如何估计删除和重新创建这些索引所需的时间或内存量,因为某些表具有超过 2B 的记录。
您能否建议如何估计删除并重新创建表上的索引需要多长时间,或者您能否建议修复分区的不同策略?
您能推荐一种不同的修复分区的策略吗?
是的,我可以!您观察到的无法分割包含数据的分区是关键。避免这种情况的普遍接受的最佳实践是在要分割的范围一侧始终有一个空分区。因此,在您的示例中(我假设是预计即将滚动到 2023 年 12 月),您还需要添加 2024 年 1 月的分区边界。然后,在 12 月的某个时间,您将添加一个2024 年 2 月的边界。通过始终比当前提前一个月(或两个月,具体取决于您的计算方式),您可以分割一个空分区,这完全没问题。
如果您很偏执,请在其中添加几个分区并提前几个月。不管怎样,我建议添加诸如“哦嘿...方案末尾的空分区少于“所需数量””之类的监控。可能需要对此采取一些措施。