联机时将SQL Server数据库移动到新磁盘

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

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

• 简单复制。使数据库脱机，复制文件，更改SQL Server中的位置，然后使其重新联机。粗略的数字估计这将花费最多五个小时，这虽然确实不能接受，但这是最简单的解决方案。

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

• SQL迁移。在新磁盘上创建一个新的1.4TB SQL数据文件，并在所有其他文件上禁用自动增长。然后依次对所有其他数据文件运行DBBC SHRINKFILE（-file_name-，EMPTYFILE）。一旦所有数据都经过处理，我将在某个时间点使用计划的窗口将MDF文件移至SSD并删除其他未使用的文件。我之所以这样，是因为它最大程度地减少了停机时间。但是我不知道这将花费多长时间，并且在发生时是否会导致性能下降。

我们没有任何负载和性能环境可以对此进行测试。我可以验证这些策略是否可以在我们的登台环境中使用，但不能影响效果，而不能用于性能。

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

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

2）将最新的完整备份还原到其他数据库名称，并指定用于根据WITH MOVE需要重新定位SSD存储上的文件的NORECOVERY选项以及该选项，以便可以还原后续的差异备份和日志备份。

3）将增量更改应用于新数据库，直到使用事务日志备份和进行最终转换为止RESTORE...WITH NORECOVERY。这将最大程度地减少最终切换到新数据库的停机时间。

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

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

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.