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

　　大多数公司花了很大代价对他们的应用程序进行了升级。但是对于另一些行业，如信用卡、银行、购物和游戏公司，升级时的停机时间是他们不能接受的。假设eBay和PayPal对系统升级一次就要花一个多小时，费用也就迅速增长至数百万，这还仅仅是直接收入损失，更不用提流失的客户了。

　　挑战

　　你的老板已经告诉你分类的应用程序需要升级到版本10，停机时间控制在15分钟之内。这种问题数据库为4+ TB并且在没有任何传输量的情况还下需要16小时进行升级。

　　真实性检查

　　你认为的最佳方法常常会失败是因为这一方案的作用领域早先并没有设定，也没有严格附着在上面。你需要把重点放在几个关键应用程序领域，这对转换很重要。在eBay案例中，我们可能会说通过升级，一些诸如拍卖、投标以及支付等等活动可以大胆进行了，而且如果不能进行反馈或者帐户合并也还是可以接受的，所以尽量避免改变任何live data，确保每个功能单元（块或者表）完整无缺并积极传送数据。

　　假设的方法

　　你采取什么方法主要取决于你的预算。在这一假定的情境中，我们使用两个群集，每个群集都有两个节点。但在相同的physical box（或群集）或服务器上，你用两个SQL Server示例就很容易模仿这个情景来运行类似VMware’s ESX的程序。让我们来检查以下数据：

　　使用两个群集和两个节点进行动态应用程序升级（点击放大图片）

　　第一步：

　　在第一步里，我们将live data迁入数据库应用程序目前的版本里。在群集一上创建另一个变化了的数据库，这个数据库包括我们为达到升级数据库目的想改变的任意表（而应用程序是动态的）。这时候最重要的部分就是决定如何在表里保持连贯性。最普遍的方法就是在你开始转换的时候存储目前的日期和参考数字。然后不断用存储程序使日期或参考数值比你之前存储的数值要大。你还可以使用其它方法，如触发器或Service Broker，但这二者都会涉及到修改原始数据库方案、增加危险性以及犯错的几率。

　　第二步：

　　第二步是另一个物理群集（或第二个示例/虚拟服务器，也取决于预算情况）。随着方案的实施情况来看，在群集二上的转换数据库和群集一上的转换数据库非常吻合。

　　由于应用程序已将live data迁进Order App DB (V9)里，在群集一上的SQL Agent job存储程序将数据迁移至群集一上的转换数据库中。一旦数据到达转换数据库中，你就能在群集一上设置replication publication，因为在群集二上已经订阅了。这一操作导致了迁进的转换数据库中的任何数据都直接转移到了群集二上的转换数据库中。

　　应用程序已将数据引进群集一上的版本9数据库中，并且将这些数据复制到了群集二上的转换数据库中，现在你就可以在群集二Order App DB里进行数据库升级操作（你已经将它们从production恢复到了某个指定的地方）。不管数据库升级要花多长的时间，live data都会被迁进群集二的转换数据库中。数据库完成升级后，你能将SQL Server Agent job迁入群集二中，这种存储程序在转换数据库中将版本9的数据表转换成为群集二上的版本10的数据库。这时你就可以对已升级的版本10数据库进行必要的配置和维护。

　　第三步：

　　如果群集二上的转换数据库几乎是空的并且客户也已经升级到了版本10，那现在就该转变群集一的指向，将所有的客户指向群集二，在此之前这些客户已经迁移了所有重要的live data。将客户指向版本10的快速方法就是SMS 或SoftGrid（应用程序虚拟化），或其它自动部署一种新的版本到大型客户基础上的方法。这种方法让你在15分钟内部署版本10 应用程序并指向最新升级群集二上的版本10。

　　总结

　　在动态时升级应用程序需要写一些自定义代码保证这些表在群集（服务器或者示例）中保持一致性。多次测试升级情景和脚本，在不同阶段修改报告确保升级顺利进行。修改各种转换数据库步骤、作业、文档以及确保一致性是一件很枯燥的工作，但是最终在顺利进行升级时还是得到了回报，至少在用户的角度解决了问题。