我们有几个 SQL Server 2005 数据库，很快会将它们迁移到新的生产服务器。这些数据库并不庞大，但足够大，因此在尽可能减少停机时间的情况下完成迁移非常困难。
由于三个数据库最为关键，因此将首先移动它们，它们的大小分别为 5、9 和 25 GB（仅数据，没有日志）。
现在有几种可能，但由于我不是一名成熟的 DBA，我想也许这里的一些人可能有更好的想法/建议。以下是我们得出的结论；
* Create a full backup, move the file and restore the backup.
这是可能的，但由于数据库相当大，这将意味着系统会出现相当严重的（几个小时）停机时间，因为数据库需要移动。
是否可以今天创建并恢复备份，然后在实际移动时进行差异恢复？到目前为止，我发现差异恢复的问题是，这些恢复总是被添加到完整备份中，这会使文件大小保持不变，并且不会减少由于将文件从一台服务器移动到另一台服务器而导致的停机时间。
为了使这“更”棘手，新数据库将配置为镜像，而旧环境则不镜像。这意味着我必须在主服务器上恢复差异备份（我不认为这会引起问题，但我想问一下。）
如果有其他更简单或更好的方法可以做到这一点，并且停机时间最少，我当然也很乐意听到。
StackOverflow 上的一位用户简单地回复道：“您可以使用镜像来实现这一点”。我对此不做过多介绍，我的看法是，我可以在新原则上创建一个镜像，然后强制镜像接管旧生产服务器。然后我禁用镜像，并重新启用镜像到新的镜像服务器。
那样的话还能用吗？
答案1
我进行过几次这种类型的迁移，对我来说最好的方法是：
完整备份（数据库正在使用）
每 n 分钟备份一次事务日志（n 取决于复制完整备份的时间）
将完整备份复制到新服务器，然后还原数据库而无需恢复（
RESTORE....NORECOVERY）复制并恢复（始终不进行恢复）事务日志
当新数据库几乎上线时，停止使用旧数据库的应用程序，备份最后的事务日志，将其复制到新服务器并使用恢复进行恢复。
现在，您在新服务器上拥有了数据库，并且停机时间非常短。
答案2
至于备份和移动数据库，我通常会在不到半小时内备份 30GB 的数据库。如果您将它们备份到连接到当前服务器的外部 USB 驱动器，然后通过 USB 驱动器将它们传输到新服务器并恢复它们，我认为它不会花费超过一个小时，加减几分钟。
答案3
我会尝试给出一个观点，
也许我错了，让其他人说，如果这不是常规方法，您可以设置事务复制到新服务器并发布和订阅数据库，这样您就可以让两个数据库在小于几秒钟的延迟内持续运行。
之后，您关闭从客户端到旧数据库的连接并等待几秒钟。
禁用复制并开始使用新数据库