我应该使用分离/复制/附加还是通过备份-恢复-重放来迁移数据？

Question

我即将着手将数据库文件迁移到新的 SAN（从旧的 SAN），并且我有几个选项可以实现这一点。(1) 有人建议我调查将完整备份恢复到服务器上新数据库的工作量。但是，(2) 我最初的计划是通过分离然后重新附加数据库将文件从旧 SAN 复制到新 SAN。

我的直觉告诉我，我宁愿分离、复制和附加，因为它看起来更安全，但这可能只是我的天真。我不想在重命名数据库的过程中错过事务或以某种方式“破坏某些东西”。

我想我的问题是我对 BACKUP-RESTORE-Replay 选项的怀疑是否合理，以及该选项的其他优点或风险是什么？

Answer 1

就个人而言，我会避免分离/附加机制。尤其是在 SQL Server 2000 中，我只是不相信您会始终恢复服务器并能够附加这些文件。我听过很多故事，这些故事并没有完全发生——仅仅因为你有一个 B 计划并不会自动使 A 计划变得合理。

有了备份/恢复，您就不必冒险执行 B 计划。如果备份失败，您的数据库仍会运行。如果恢复失败，您的旧数据库仍在运行。在这两种情况下，您都可以恢复原始数据库的操作并稍后重新访问该计划。除了停止 SQL Server 和/或分离的额外安全性之外，这也意味着您可以测试备份/恢复方法之外的 hoo-has（假设您当前有空间来执行备份和另一个实例来测试恢复）。您无法在不分离数据库或停止 SQL Server 的情况下真正测试分离方法，而且在适当的维护窗口之外很难做到这一点。最后，使用其他方法，在分离或关闭 SQL Server 之前，您甚至无法开始复制文件。

从 SQL-Server 下拉出驱动器方法的另一个好处是：通过备份/恢复，您可以将各种文件移动到与以前不同的驱动器号。例如，当我们迁移到新的 SAN 时，我们能够拥有更多卷，因此我们可以将 tempdb 移动到 T:\（以前不存在），将一些数据和日志文件移动到新的驱动器号等。更好地利用我们拥有的所有新 I/O 容量。如果您只是关闭 SQL Server，然后换出磁盘，则需要具有相同的驱动器号和相同数量的卷。

Answer 2

由于 SAN 重新配置和迁移，我过去几乎一直在移动数据库。

假设您一次移动整个服务器，我会采用类似于您的路径 #2 的方法。（如果您一次移动一个数据库，并最终移动服务器上的每个数据库，那将会有更大的问题，因为您必须更改文件的路径。）

请注意，“single_user”并不一定意味着您。你可以去 DBCC CHECKDB 一个数据库并且无法进入，因为有人已经在那里了。准备一个脚本，您可以运行该脚本以从数据库中引导“除您之外的所有人”并将其保存在一个方便的地方。请注意，SQL 2000 没有与更现代的版本相同的“将所有人排除在外”的功能。

一种古老的技巧是暂停 SQL Server 服务。这将阻止新的登录，但任何已经连接的人都可以照常继续。所以：通过 SSMS 窗口连接，这样你就可以工作，然后暂停服务，然后踢出不需要的连接，通过 SSMS 命令窗口（不是 GUI，它建立和断开大量连接）做你的事情，然后取消暂停服务。警告：我不确定这将如何在集群上发挥作用。它可能想要故障转移。

在您完成工作之前，有一种方法可以让所有应用程序用户远离服务器，这很方便。否则，当您尝试做某事时，连接可能会开始弹出，这可能导致资源争用和/或缓慢。我过去曾使用过以下方法，具体取决于具体情况： 关闭应用服务器 使用 ALTER DATABASE .. SET RESTRICTED_USER（如果应用帐户是 db_owner、sysadmin 或 dbcreator 角色的成员，这是一个问题。 ) 告诉用户系统将在某个特定时间下线，例如周日早上。（这在“真正的”24x7 环境中不起作用。）拔下面向应用服务器或用户的 NIC。（在这种情况下，我可以通过连接到仅限管理员的网络或通过 ILO 的另一个 NIC 进入。）

分离大量数据库并重新附加它们可能需要大量工作。如果这样做，请确保提前编写了“附加”脚本。

我在停止 SQL Server、复制所有内容、更改驱动器号和启动 SQL Server 方面取得了很多成功。没有分离/连接。只要 SQL Server 关闭并且您正在复制（而不是 MOVING）文件，您就不会遇到太多麻烦，即使您正在移动系统数据库。由于路径相同，SQL Server 在服务关闭时不会意识到任何变化。只要确保您将驱动器号指向正确的卷，否则事情会对您不利。

我最常见的问题是没有正确获取文件目录上的 ACL。SQL Server的更现代的版本是在设置好刚刚权限，虽然旧版本的服务帐户需求似乎不那么挑剔。如果您忘记设置 ACL，并且服务帐户不是本地管理员（我不建议这样做），则实例启动时可能无法打开一个或多个数据库。不要惊慌，只需更改 ACL 并附加数据库即可。

我一般使用 ROBOCOPY 来做这类工作。有一个命令行开关可以保留 ACL。

使用 CRC 计算/验证并不是一个坏主意，但我从未这样做过。当数据库恢复时，我会在所有数据库上运行 CHECKDB()。我通常会为此提前准备一个脚本，而不是依靠手动启动维护工作。这样，我可以先检查几个较小的数据库，然后再检查可能需要几分钟或几小时才能运行的大型数据库。我怀疑 CRC 检查（或 Redgate 数据比较工具）是否会发现 CHECKDB() 会遗漏的东西，如果确实如此，SQL Server 将无法修复它。

复制文件后，但在重新启动实例之前，我将通过重命名文件夹之一来稍微更改 OLD 文件夹的文件路径。这是针对“哎呀，服务器仍然指向旧文件”问题的额外检查。

不要急于删除旧文件并恢复旧存储上的空间，并确保您的完整备份已成功运行。测试将其中几个备份恢复到其他地方。一旦您有良好的 checkdb() 运行和良好的完整备份，那么您就可以考虑删除旧存储并关闭 Lefthand。

我在这些迁移中遇到的最糟糕的问题发生在我以为我已经完成之后。那将是 SAN 管理员告诉我发生了一些事情并且我的文件系统被打乱了。（重新分区，重新格式化，再次复制。）

另一个有趣的问题是 SAN 无缘无故变慢。如果您认为复制数据需要 10 个小时，而在第 9 小时复制了 30%，那么您就有问题了。观察传输时间（robocopy 显示复制百分比并给出时间估计，或者您可以使用 Perfmon）并在出现问题时制定备用计划。

另外，我不确定您的卷是否会为您分区，但您可能希望确保它们使用 1 MB 的偏移量。在 Windows Server 2008 及更高版本上，这应该不是问题。在较旧的操作系统上，它是。关于这个有很多可搜索的东西，你的存储人员应该知道它，但我想问一下。