我有一个 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 并删除其他未使用的文件。我喜欢这个，因为它最大限度地减少了停机时间。但我不知道这需要多长时间，以及它在发生时是否会导致性能下降。
我们没有任何类型的负载和性能环境来测试这个。我可以验证这些策略是否适用于我们的暂存环境，但不是影响，而不是性能。