在线时将 SQL Server 数据库移动到新磁盘

Question

我有一个 1.4TB 的 SQL Server 数据库，它在磁盘 I/O 方面遇到了很大的困难。我们已经在服务器中安装了一个新的 SSD 阵列，它将解决我们所有的问题，我们只是在讨论移动数据库的最佳方式。理想情况下，如果我们可以在不停机的情况下完成这项工作，那就最好了。但是，如果要在两天性能不佳（例如复制数据时）与两小时停机时间之间进行选择，则后者可能更可取。

到目前为止，我们提出的解决方案是：

• 简单的复制。使数据库脱机，复制文件，更改 SQL Server 中的位置并使其重新联机。粗略的数字估计这最多需要五个小时，这不是真的可以接受，但这是最简单的解决方案。

• 块级复制。使用类似 rsync 的实用程序，我们在数据库启动时在后台复制文件。当我们准备好迁移时，我们使数据库脱机，使用此实用程序进行差异复制，然后将 SQL 服务器指向新文件并使其联机。这里的时间未知。我们不知道对 1.4TB 进行差异分析并复制它需要多长时间。我们的另一个担忧是块级副本会使文件处于 SQL Server 无法读取的某种状态，我们将浪费时间。

• SQL 迁移。在新磁盘上创建一个新的 1.4TB SQL 数据文件并禁用所有其他文件的自动增长。然后依次对所有其他数据文件运行 DBBC SHRINKFILE(-file_name-, EMPTYFILE)。处理完所有数据后，我将在某个时间点使用预定窗口将 MDF 文件移至 SSD 并删除其他未使用的文件。我喜欢这个，因为它最大限度地减少了停机时间。但我不知道这需要多长时间，以及它在发生时是否会导致性能下降。

我们没有任何类型的负载和性能环境来测试这个。我可以验证这些策略是否适用于我们的暂存环境，但不是影响，而不是性能。

Answer 1

移动整个数据库的一种方法是使用BACKUP和RESTORE。数据库在最后一次切换期间将不可用，但停机时间应尽量减少。此过程假定FULL或BULK_LOGGED恢复模型：

1) 执行完整备份（或使用您现有的备份）。

2) 将最新的完整备份恢复到不同的数据库名称，指定根据WITH MOVE需要重新定位 SSD 存储上的文件的NORECOVERY选项以及该选项，以便可以恢复后续的差异和日志备份。

3) 对新数据库应用增量更改，直到使用事务日志备份和RESTORE...WITH NORECOVERY. 这将最大限度地减少最终切换到新数据库的停机时间。

4) 要切换到新数据库，使应用程序脱机，执行最后的事务日志备份，然后应用到新数据库WITH RECOVERY。最后，将原始数据库重命名为不同的名称，并将重定位的数据库重命名为原始名称。在您方便时删除旧数据库。

在 SIMPLE 恢复模型中，您可以使用类似的过程，但没有步骤 3 的事务日志备份/恢复。相反，在最后一步使用差异数据库备份/恢复。这可能需要更多的停机时间，具体取决于自初始FULL备份以来的更改量。