小编rda*_*pan的帖子

我需要我所能获得的所有帮助才能成功重建索引。特别是有关事务日志管理的专家建议。

背景

目标数据库是在聚集列存储索引 (CCIX) 中托管 3 个大表的 DW 数据库。最大的表叫做模拟。它拥有约 370 亿行和约 600 GB 的高压缩数据。根据我们使用较小表的初步估计，150 GB CCIX 表可以扩展到 5 TB，因此我们为这次重建提供了额外的 29 TB。

• SQL Server 企业版 2016
• 恢复模式 = 简单

为什么我们必须这样做？

在我们的 ETL 服务的第一个版本中，数据在加载到 CCIX 之前没有先合并和排序。这导致 CCIX 的非最佳使用，因为许多行段在压缩之前没有完全填充。最佳段必须压缩 1,0485,76 行，并且必须按时间排序，以便基于时间的查询可以在 sql server 中获得最多的行组消除，并减少要处理的段。随着更多的文档可用，我们将学习更多的 CCIX。

我的对齐摘录在这里 https://drive.google.com/file/d/0BzGLNskaj70UQUtZYW9CZF9iUUk/view?usp=sharing

新的 ETL 保证数据在加载到 CCIX 之前及时整合和排序。所以未来的加载将被排序，我们在这里关注的是在首次加载期间加载的现有数据。

有关完整的案例描述，请阅读此处。 https://drive.google.com/open?id=0BzGLNskaj70URmZURlVDWVNYd2M

这是我们的第二次尝试，尽管新脚本具有基于分区的索引重建，但我可以看到日志文件仍在堆积。我们需要控制这一点。

我的问题是：

1. 我已经执行了第二次尝试（正在进行），是否可以检查哪些分区已经被处理和排序？我在重建脚本中有 OFFLINE = ON 。

2. 当基于分区的索引重建正在进行时，我们如何管理事务日志的大小？我们需要对此进行检查，并在可能的情况下定期截断每个分区。

3. 由于日志文件中的空间不足，索引重建最初失败。我们添加了一个新的日志文件并使用单独的磁盘。但是我们如何确保这不会在第二次运行中再次发生？基于分区的重建是否足以保证我们能够成功重建？

感谢你的帮助。

按分区重建脚本（第二次尝试）——进行中

已用时间：17 小时 34 分钟

--create a new clustered row index (CRI)
CREATE CLUSTERED INDEX [Analog_ColumnStoreIndex] 
ON [dbo].[Analog]
( …