在计划升级SQL Server时（如升级到SQL Server 2008），我们要考虑的最重要方面就是测试。通常人们会将数据迁移到SQL Server的最新版本，并设想一切都可以解决。一般会是这样的情况，但是也不确定。特别是从SQL Server 2000升级到SQL Server 2005，这似乎是最未经测验的升级路径。

　　假设SQL Server管理员要测试他们数据库平台上每个存储程序变化，每次在做最少测试时，数据库本身的变化都会给不断我带来惊喜。在服务包升级过程中不进行相关测试也可以理解，因为在此过程之后并不会有太大的改变。但是升级到SQL Server的不同版本就会给系统带来很大的变化。

　　在系统升级之前，你开始应该升级开发和质量保证（QA）系统到新版本上。这样开发人员就可以直接看到可能出现的问题。升级QA系统治所以重要是因为就是最有可能执行测试的地方。除了测试升级系统的实际过程外，你还应该进行数据库的全回归测试（full regression testing）和满负荷测试（full load testing）。这样做有助于你识别问题出现的地方。

　　如果你不测试会发生什么事情？

　　之前，我工作的公司执行了从SQL Server 2000到SQL Server 2005的就地升级。运行在32位硬件上，而系统内存只有4GB。它还大量用到了动态SQL，因为每个大过程都在数据库里有一套自己的表。和SQL Server 2005处理procedure cache所做的变化一起，升级让SQL Server的CPU负载从在SQL Server 2000上的20%上升到SQL Server 2005的100%。在SQL Server 2000上，SQL Server能在plan cache中管理动态SQL，但是SQL Server 2005还不能以那种方法来操作。所以每次运行程序时，SQL Server都要重新编译执行计划。

　　目前我能跟大家讨论的，有关在QA之前的无负载测试并不多。这种失败的升级结果无非就是在两种解决方案中二选一。选项一就是升级到64位的硬件和64位的SQL Server，选项二就是降级到SQL Server 2000。但是降级就意味着要进行周的数据库恢复，还要用数据转换服务 (DTS) 将数据从SQL 2005数据库迁移到SQL 2000数据库。

　　如果在QA中做了充分的测试，特别是负载测试，这个问题就可以在操作系统升级之前解决。但就是因为缺少做充分测试的费用才导致了该公司损失了好几万美金。其他费用还包括Microsoft Professional Services团队、公司外包数据库管理加班工资、第三方咨询费用和客户取消服务的费用。

　　在你做测试的时候会发生什么？

　　在SQL Server升级的中进行充分测试能够大大减少来源于升级问题的压力。我工作过的另一家公司就是从SQL Server 2000升级到SQL Server 2005。在升级过程中，我们进行了full code检查，运行SQL Server Upgrade Advisor 以及查找Microsoft Knowledge Base的问题。每当我们完成程序一个部分，我们就把这部分发送到应用测序中。

　　并且每个部分都完成后，我们还要进行全回归测试。通过测试我们才能确定哪些问题应该反馈到开发团队进行解决。多亏进行了充分测试，我们成功完成了系统升级，并且没有出现任何问题。其实那些系统大小的问题对你的影响并不大，我们测试的系统就是一家大型汽车金融借贷公司的系统，平均每年都要处理十多亿美元的汽车借贷。

　　虽然这两个例子是两个极端的事例，但是它们却很有代表性。通过测试，你可以发现一些潜在的问题。而没有进行测试，那你就好像无头苍蝇。更复杂的问题就是，解决降级到以前的版本所遇到的问题是一个复杂的过程。如果产品已经有了新版本，将会更加艰难。

　　随着微软下一个版主的发布，测试变得越来越重要。微软已经考虑下一个新版本中将不包含SQL Server 2005和SQL Server 2008中的一些特性。这一点将对升级到将来的版本产生很大的影响，所以测试将成为最为全面的解决方案。