这篇文章是介绍数据库升级的案例记录一系列文章的第二部分，它描述了如何将在Windows 2000服务器上运行的SQL Server 2000 Active/Active群集升级到Windows Server2003/SQL Server 2005 Active/Active群集。咨询师Matthew Schroeder将对IT世界和数据库管理团队的技术方面和决策过程方面进行详细阐述。这篇文章是基于两个在线升级：一个是商业网、另一个是eBay排序系统。由于考虑到机密原因，我们改变了实际方案的某些细节。

　　在这一系列的文章的第一部分中，你已经了解到了这一案例学习过程中所涉及到的团队以及关于升级得一些正、反面的选择。现在让我们选择一下我们的升级策略，接下来就是在我们升级本地的SQL Server群集时，真正将它们迁移到临时服务器运行应用程序。大致分为四个步骤：

　　步骤1：我们的应用程序引入本地Active/Active SQL Server 2000群集。　

　　图1：应用程序引入SQL Server 2000群集

　　步骤2：我们需要建立第二个（过渡）服务器，然后将SQL Server 2000数据库迁移至该服务器中。通过应用程序我们可以完成这一步，log shipping或者是将数据库恢复到过渡服务器中，最后在应用程序脱机时将“末端”事务日志恢复在过渡服务器中。我们的这一选择就是为了“将数据库恢复到过渡服务器中”。这样我们的应用程序就只需要在对末端事务日志进行备份时保持脱机状态，并将它复制到过渡服务器中同时也将事务日志也被恢复到了过渡服务器中（图2）。我们限制了minimizing downtime 。这是因为，当应用程序在过渡服务器上运行时，本地Active/Active群集就被重新创建了，并且在还附带有Windows Server 2003/SQL Server 2005。

　　图2：将数据库存储到过渡服务器

　　步骤3：我们会从过渡服务器返回到在Windows Server 2003/SQL Server 2005上重建的本地Active/Active群集。这个步骤和步骤1非常相似，是有我们将数据库迁移至本地的服务器，我们现在才能了解SQL Server2005的技术。我们能够从备份和恢复、log shipping以及复制中选择（现在我们在SQL Server2005上）数据库镜像。

　　如果我们用log shipping和复制来返回本地集群，那么本地box在迁移的过程中可能会被损坏——即使我们很小心地保护也不会有什么好转。我们不想冒险将过渡服务器上的数据库从准备好的带本地数据库的sync上迁移出来。备份和恢复也是一个选项，但是它要求对末端事务日志进行备份、复制和恢复时的minimizing downtime。既然我们能够利用SQL Server 2005，我们就能不需要任何minimizing downtime利用数据库镜像迁移到本地集群上。由于镜像通常是恢复模式，我们就不关心本地数据库从过渡数据库上的sync上迁出。

　　图3：数据库镜像在恢复模式中

　　步骤4：为了让本地Active/Active群集成为主要的服务器、过渡服务器成为次要服务器，我们要将数据库镜像转移。这时该应用程序（假设我们在运行VS 2005+ MDAC）将自动指向新的主要服务器。

　　图像4：Application traffic指向你新的SQL Server

　　注：如果你目前还没有使用最新版本的MDA，你就需要在修改指向新的主要服务器的连接串。那时候应用程序才能正常运行。

　　如果你仅仅是没有的充足的时间，那么在升级到SQL Server2005 时使用过渡服务器和Windows Server 2003是一个很具体的方法，也是你最好的选择，这一连串的步骤也尤为关键并且它们也起到了一些作用。

　　在第三部分中，我将向你们介绍minimizing downtime和你应该考虑的事情。