1

I am trying to partition a huge table in SQL. Its size is 15 TB with millions of records. The main idea is to save the coming data onto different disks by creating new filegroup where the current disk can't be expanded any more.

I created the needed of filegroups, files, partition schema and partition function, but when I created the clustered index it took too much space (more than 200GB) and was still running so I stopped it.

My question: is there a way to partition an existing huge table without creating a clustered index that is taking too much space? Or is there a way to save the new coming data to a different disk?

4

2 回答 2

3

为了避免创建 15TB 索引（当然，您可以在新磁盘上的新文件组上创建）的痛苦，您可以创建一个新的分区表（或者不分区，如果您不需要管理/存档/purge old data ever) 从头开始​​，开始在那里写入所有新的传入数据，然后慢慢地将数据移过来。

在这里借用我自己的答案：

  • 在新磁盘上创建一个具有足够分区的新分区表，以愉快地划分所有现有的和一些合理的时间到未来的未来数据
  • 创建一个union all包含两个表的视图（最简单的方法可能是重命名当前表并临时用具有旧表名的视图替换它）
  • 将新写入直接写入新的分区表
    • 希望您通过存储过程或更改目标名称的最小位置来控制写入
    • 如果没有，您可以在视图上使用代替触发器来将写入定向到分区表
  • 在后台，开始delete top (@batchsize) output deleted.* into new_table from old_table
    • 这与完成所有事情需要多长时间无关，诀窍是优化批处理大小，以便在完成任务和不会导致阻塞太久之间取得平衡，并确保在每个任务之间放置一些日志备份n 批次，如果它们还没有足够频繁地安排（这里有更多信息）
  • 一旦所有数据都回填，您可以删除旧表，然后将视图更改为不再union all（或摆脱它并重命名新表）

如果将所有旧数据回填到新分区方案中需要两周时间，那又如何呢？用户无需等待两周；他们只在等待任何单个批次（即使那样，这在很大程度上只是查询正在移动的数据的人，而不是新数据）。

于 2021-10-21T11:49:52.710 回答
2

主要思想是通过在当前磁盘无法再扩展的地方创建新文件组，将即将到来的数据保存到不同的磁盘上。

或者有没有办法将新的数据保存到不同的磁盘？

是的。分区对于这个来说是大材小用。只需将新文件添加到现有文件组并将新文件放在新磁盘上即可。由于 SQL Server 的Proportional Fill Algorithm，几乎所有新分配都将来自新磁盘上的新文件。

于 2021-10-21T13:02:16.313 回答