我们有一个旧的SQL 2000服务器，我们称之为“oldSQL2K”和一个新的SQL 2008服务器，我们称之为“newSQL2K8”。 两者都在生产。 oldSQL2K上有大约90个用户数据库，可以通过ODBC连接进行访问，也可以通过SQLlogin进行访问。
我正在寻求如何最好地将数据库从oldSQL2K迁移到newSQL2K8的build议。
我通过旧的SQL备份和新的SQL还原手动迁移了大约十几个数据库。 我已经将所有的SQL日志从旧迁移到新的，这样就完成了。
作为一个实验，我尝试了一个简单的DNS名称更改，但当然失败了。
以下是挑战：我们支持“必须保持活力”的遗留应用程序之一是将oldSQL2000服务器名称烘焙到编译后的代码中，并且源代码不见了！ 长话短说，不是我的错，但现在我的问题。 这个程序在大约50个工作站上运行。
我们的服务中心已经确定了大约1000个工作站将受到这种迁移的影响。 噢。
我们在所提到的50个工作站上都有SQL客户端networking实用程序，并且可以在此处使用别名。 在其他工作站和服务器上安装它虽然是我想尽可能避免的。
所以人们，如果是你，你将如何进行这个迁移？
我会像现在这样迁移，但隔离那些不能轻易修改的“必须保持活跃”的应用程序，并将其保留在旧的服务器上。 然后虚拟化SQL2000服务器，如果你有一个虚拟机环境。 旧的应用程序可能不会从移植到SQL2008中受益，除非你有性能问题，需要更多的处理空间，虚拟机将不断提醒真正应该被replace的坏应用程序。
虚拟化剩下的东西是一个彻底的想法….或者，你可以将它们移动到SQL Server 2008（testing之后，他们仍然工作），并使用DNS魔术重新署名。 我已经看过很多次了 – 虽然不是很干净，但是很有效。
我发现自己处于类似的catch-22情况之前，所采取的方法是转移到另一个SQL 2000服务器，可以很容易地更改，但不能升级到2008年，一旦你的应用程序（就像你提到的那个），在服务器名称不能改变的地方，我们从域中删除了旧的服务器，并closures了它，在一个指向新的SQL服务器的DNS别名中存根。 使用隔离networking可以帮助您解决在生产环境中遇到的所有问题，但不会干扰任何操作。
如果你有一个孤立的networking（或者可以创build一个），你可以在其中复制服务器名称，并且至less有一个客户端要testing，我将使用它进行评估。 这将允许您testing一个DNS别名。 复制每个给定数据库的备份，并将其恢复到SQL 2008 x64或您的prod服务器将要使用的任何版本/体系结构，并针对每个数据库以不同的兼容级别进行testing。
我希望这有助于一些想法！