【发布时间】：2017-12-29 17:04:12
【问题描述】：
我们正在 SQL Server 2012 中重新设计一个非常大（~100Gb，分区）的表。
为此，我们需要将旧（现有）表中的数据转换为生产服务器上新设计的表。新表也已分区。行仅附加到表中。
问题是很多用户都在这台服务器上工作，我们只能在服务器负载不重（一天几个小时）的情况下分块执行此转换过程。
我想知道是否有更好更快的方法？
这次我们将在几天内完成转换过程（然后将我们的应用程序切换为使用新表），但是如果表是 1Tb，我们该怎么办？还是 10Tb？
PS。有关当前流程的更多详细信息：
这些表根据 CloseOfBusinessDate 列 (DATE) 进行分区。目前我们在服务器负载较低时运行此查询：
INSERT INTO
NewTable
...
SELECT ... FROM
OldTable -- this SELECT involves xml parsing and CROSS APPLY
WHERE
CloseOfBusinessDate = @currentlyMigratingDate
每天约有 100 万行旧表中的行转换为新表中的 2 亿行。
当我们完成转换过程后，我们将简单地更新我们的应用程序以使用 NewTable。
【问题讨论】：
-
这取决于初始模式和目标模式。您是否要将一张桌子转换为多张桌子？您要更改分区方案吗？分区是手动的还是自动的？行是否仅附加到表中，或者它们是否也被更新和/或删除？可以通过将一张表包装在视图中来使其“显示为”另一张表吗？您的问题目前过于宽泛，请详细说明您所做的更改，我们可以提供具体建议。
-
使用 SP_Rename 可以工作。将现有表命名为 _OLD，将新表更改为生产名称，并确保所有 FK 都已计算在内。
-
“不知道有没有更好更快的方法”。可能。由于我们不知道您现有的代码是什么样的，我们怎么知道？
-
如果没有 UPDATE 或 DELETE，只有 INSERT 到表的末尾，那么一次迁移一个分区（或分区的一部分）应该意味着您的迁移活动不会阻塞任何其他用户进程？如果没有更具体的细节，这就像在问“如果我仍然需要它来工作，修理我的汽车的最佳方法是什么？”但没有告诉我们你如何使用它来工作，你正在做什么维修等等......
-
仍然没有太多细节。 SELECT 的执行计划是否优化？您是否在插入时获得最少的日志记录？文件是否已预先增长到足够的容量？
标签： sql sql-server database sql-server-2012