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