主页 / dba / 问题 / 123714
Accepted
seamus
Asked: 2015-12-16 03:17:30 +0800 CST

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

  • 772

我有一个 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 并删除其他未使用的文件。我喜欢这个，因为它可以最大限度地减少停机时间。但我不知道这需要多长时间，以及它是否会导致性能下降。

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

sql-server ssd

2 个回答

  1. Best Answer

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

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

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

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

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

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

    • 16 
  2. 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.
    • -6

相关问题