Answers:
就个人而言，我会避免分离/连接机制。尤其是在SQL Server 2000中，我只是不相信您将始终备份服务器并能够附加这些文件。我听说过很多故事，这些故事并非纯属偶然-只是因为您拥有计划B并不能自动使计划A变得明智。
使用备份/还原，您不必冒险进入计划B。如果备份失败，则数据库仍处于启动状态。如果还原失败，则您的旧数据库仍处于启动状态。在这两种情况下，您都可以还原原始数据库的操作并在以后重新访问该计划。除了在停止SQL Server和/或分离方面提供额外的安全性之外，这还意味着您可以在备份/还原方法之外测试hoo-has（假设您当前有执行备份的空间，而另一个实例可以测试备份/还原方法）。恢复）。如果不分离数据库或停止SQL Server，就无法真正测试分离方法，而在适当的维护时段之外很难做到这一点。最后，使用其他方法，直到分离或关闭SQL Server之前，您甚至无法开始复制文件。
SQL Server下从驱动器中拉出驱动器的另一好处是：通过备份/还原，您可以将各种文件移动到与以前不同的驱动器号。例如，当我们迁移到新的SAN时，我们可以拥有更多的卷，因此我们可以将tempdb移至T：\（之前不存在），并将某些数据和日志文件移至新的驱动器号，等等。更好地利用我们拥有的所有新I / O容量。如果只是关闭SQL Server然后换出磁盘，则需要具有相同的驱动器号和相同数量的卷。
由于SAN重新配置和迁移，我过去几乎一直在移动数据库。
假设您一次移动一台整个服务器，那么我将采用类似路径＃2的方法。（如果您一次移动一个数据库，并最终在服务器上处理每个数据库，那将是更大的问题，因为您将不得不更改文件的路径。）
请注意，“ single_user”不一定表示您。您可能进入DBCC CHECKDB数据库，但由于有人已经进入而无法进入。准备一个脚本，您可以运行该脚本以从数据库中引导“所有人，但您”，并将其放在方便的位置。请注意，SQL 2000没有与更现代的版本相同的“保持所有人”功能。
一种老技巧是暂停SQL Server服务。这将阻止新的登录，但是已经连接的任何人都可以照常继续。因此：通过SSMS窗口进行连接，这样您就可以进行工作，然后暂停服务，然后踢出不需要的连接，通过SSMS命令窗口（不是GUI，它会建立并中断许多连接）来完成您的工作，然后取消暂停服务。警告：我不确定在群集中如何播放。它可能要进行故障转移。
在完成工作之前，有一种方法可以使所有应用程序用户不进入服务器。否则，在您尝试执行操作时，连接可能会突然弹出，这可能导致资源争用和/或速度变慢。过去，我根据实际情况使用了以下方法：关闭应用程序服务器使用ALTER DATABASE .. SET RESTRICTED_USER（如果应用程序帐户是db_owner，sysadmin或dbcreator角色的成员，则是一个问题。 ）告诉用户系统将在某个特定时间（例如，周日早上）离线。（这在“真正的” 24x7环境中不起作用。）拔出面向应用程序服务器或用户的NIC。（在这种情况下，我可以通过连接到仅管理员网络的另一个NIC或通过ILO进入。）
分离大量数据库并重新附加它们可能是很多工作。如果这样做，请确保事先编写了“附加”脚本。
我在停止SQL Server，复制所有内容，更改驱动器号和启动SQL Server方面取得了许多成功。没有分离/附着。只要关闭SQL Server并且要复制（而不是移动）文件，即使正在移动系统数据库，也不会遇到太多麻烦。由于路径相同，因此在服务关闭时，SQL Server不会意识到任何更改。只要确保将驱动器号指向正确的卷，否则对您来说会很不利。
我最常见的问题是文件目录中的ACL没有正确。较新版本的SQL Server更擅长仅设置服务帐户所需的权限，而较旧版本似乎不太麻烦。如果忘记设置ACL，并且服务帐户不是本地管理员（我不建议这样做），则实例启动时可能不会打开一个或多个数据库。不要惊慌，只需更改ACL并附加数据库即可。
我通常使用ROBOCOPY进行此类工作。有一个命令行开关可以保留ACL。
使用CRC计算/验证不是一个坏主意，但我从未做到过。当数据库恢复时，我对所有数据库都运行CHECKDB（）。我通常会提前为此准备脚本，而不是依靠手动启动维护工作。这样，我可以先检查几个较小的数据库，然后再检查可能需要花费数分钟或数小时才能运行的大型数据库。我怀疑CRC检查（或Redgate数据比较工具）是否会发现CHECKDB（）会丢失的内容，如果这样做，SQL Server将无法对其进行修复。
复制文件之后，但在重新启动实例之前，我将通过重命名其中一个文件夹去稍微更改OLD文件夹的文件路径。这是针对“糟糕，服务器仍指向旧文件”问题的额外检查。
不要着急删除旧文件并恢复旧存储上的空间，并要确保完整备份已成功运行，请确保两次操作。测试将其中一些备份还原到其他位置。一旦您拥有良好的checkdb（）运行和良好的完整备份，便可以考虑删除该旧存储并关闭Lefthand。
这些迁移给我带来的最糟糕的问题发生在我以为自己完成后。那将是SAN管理员告诉我发生了什么事，并且我的文件系统已混乱。（已分区，重新格式化，再次复制。）
另一个有趣的问题是，SAN毫无理由地运行缓慢。如果您认为需要花费10个小时来复制数据，并且在第9点的小时数中已将您的数据复制了30％，那么您就遇到了问题。观察传输时间（自动复制显示已复制的百分比并提供时间估计，或者您可以使用Perfmon），如果有问题，请制定备用计划。
另外，我不确定是否可以为您的卷进行分区，但是您可能需要确保它们使用的是1 MB偏移量。在Windows Server 2008和更高版本上，这应该不是问题。在较旧的操作系统上，是这样。上面有很多可查询的内容，您的存储人员应该知道这一点，但是我想问一下。
首先，我将考虑仅使用存储阵列的功能来处理数据移动的选项。如果由于供应商不支持而无法使用它们，则说明您没有购买，或者SAN管理员不知道该怎么做...
然后，我只需使用以下步骤。
而已。
据SQL Server所知，没有任何变化，因此不需要分离/附加。而且，如果确实发生了可怕的错误，则您已将数据库的旧副本放在旧存储阵列上的旧LUN上。故障恢复只是更改驱动器号的问题。