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

　　数据库管理员一般都从架构开始，这样就造成了他们对升级过程中如何监测SQL Server不清楚。到目前为止，升级最终要的部分就是进行计划，但是很少有公司资源筹划一次完整的负载升级测试。遗憾的是，当系统在产品的重压之下，SQL Server升级中有效负载测试就开始进行了。

　　挑战

　　我们假设公司要么使用数据库镜像、复制，要么使用的是两个系统合并升级成的一个系统。我们检查一下如何监控复制以及数据库镜像保证所有的数据以有效可靠的方式进行传输：

　　监控SQL Server复制

　　监控复制部分是为了确保所有在转换数据库中的的记录都能够被迁到目的数据库中，这要求你执行的操作就是点击“复制”和“启动复制监视器”，出现监视屏，如图一所示：

　　图一：点击“复制”和“启动复制监视器”。（点击放大图片）

　　这一屏幕的出现让你对执行结果有了初步的印象。那么“订阅”操作执行了吗？性能和滞后时间又如何呢？微软在SQL Server 2005 上增加了一项非常好的性能：跟踪令牌（tracer token）。跟踪令牌主要是插入复制链里的数据包，（主要是让你能够为分发服务器测量时间（可以在同一台机器上或是它自身的box），它还测量从分发服务器到订阅服务器的时间。（如图2）

　　
　　图二：SQL Server 2005里的跟踪令牌为分发服务器测量时间而且还测量从分发服务器到订阅服务器的时间。（点击放大图片）

　　
　　初始数据库快照进行订阅复制时，就会显示出一个感叹号。这并不是说出现了问题，而是在复制数据库快照时造成的加载。一旦这两个数据库同步了，感叹号就会消失，除非就是服务器真的出现超载现象。

　　如果感叹号还存在，你可能会使用跟踪令牌来检查是否发布服务器、分发服务器和订阅服务器出现了滞后时间。在这种状况下影响滞后时间的主要因素是CPU、I/O、网络和RAM。

　　如果这里的某一个方面实际上出现了性能减缓的现象，那就要切换All Subscriptions表、双击“订阅”获取错误表。这时候的祸首通常是架构、作业或是起始误差。

　　在SQL Server中监控数据库镜像

　　Monitoring Database Mirroring不是很清楚，因为它没有单独的文件夹。如果设立了数据库镜像，就只需要点击主数据库的或者是镜像数据库、任务，然后选择Launch Database Mirroring Monitor，就会出现图三中的屏幕。

  图三：如果设置了数据库镜像，就选择Launch Database Mirroring Monitor。（点击放大图片）

　　如果你已对有最近事务日志的镜像示图初始化，那这两个数据库应该在你到达如上图的屏幕之前就同步了。如果数据库镜像是为了确保高安全性而设置的，例如在镜像上面执行事务而不是主要数据库上执行，这一屏会让你了解管理费用是由“Mirror commit overhead”产生的。如果你才用了高可用性模式，它还会对于你镜像环境可能有多落后这一方面有很大的启发。

　　由于处于复制状态，性能问题在这些领域存在着同样的问题。所以如果在上面的这个屏幕上显示了任何问题，它们应该很容易被发现。

　　总结

　　这一系列的文章分为五个部分，我们通过以一些范例架构设计出对OS/SQL Server以及SQL Server动态应用程序升级计划。这些架构能够一起或单独使用。我们还介绍了如何监控数据库镜像以及监控数据库复制，这些都取决于你采用什么样的升级方式。

　　你应该通过升级定期回顾一下复制和数据库镜像性能。你可以在数据库镜像中设置警告，这些警告还可以被SQL Server Agent用来发送DBA警告或者MOM/SCOM（MS系统监控工具）以便于选取事件，还可以被它们用来给合适的群体发送警告。和SQL Server Agent or MOM/SCOM相比较，如果它本身就不发送警告，那么在复制时就很难有警告提示了。