SQL Server数据库升级
这一系列的文章分为五个部分,我们通过以一些范例架构设计出对OS/SQL Server以及SQL Server动态应用程序升级计划。这些架构能够一起或单独使用。我们还介绍了如何监控数据库镜像以及监控数据库复制,这些都取决于你采用什么样的升级方式。咨询师Matthew Schroeder将通过IT世界和数据库管理团队的技术方面和决策过程方面进行详细阐述。这些文章是基于两个在线升级:一个是商业网、另一个是eBay排序系统。由于考虑到机密原因,我们改变了实际方案的某些细节。
目录:
-
>升级团队组成以及升级选项的优缺点
项目组由许多不同部门的成员组成。如果数据库在离站点比较远的地方,那么网络就负责监视网络负载、硬件负责人员主要负责检建设一些必要的基础结构,如群集——SANs和虚拟机(微软或者Vmware)以及当重系统负载在多个系统之间迁移时监视系统性能。
总之,应用程序的这种升级方式需要以下人员进行协助:一名网络负责人,一名硬件负责人(约三天时间),一名DBA(一周时间)、两名应用程序支持负责人以及两名或三名终端用户。 -
>在升级本地SQL Server群集时迁移到临时服务器的步骤
在这一系列的文章的第一部分中,你已经了解到了这一案例学习过程中所涉及到的团队以及关于升级得一些正、反面的选择。现在让我们选择一下我们的升级策略,接下来就是在我们升级本地的SQL Server群集时,真正将它们迁移到临时服务器运行应用程序。大致分为四个步骤。
-
>最小停机时间以及需要考虑的问题
在第二部分已经指出,升级到SQL Server 2005和Windows Server 2003的第一步就是将应用程序指向另一个过渡服务器,该服务器在主要群集重建时还能够运行。如果你仅仅是无法负担几个小时的时间,那么这就是一个相当详细的过程,也是最佳的操作过程。步骤顺序也非常重要,因为一些小性能就能使你的操作失败。本节专家将介绍最小停机时间的一般概念以及你需要考虑的一些事情。
-
>动态应用升级
大多数公司花了很大代价对他们的应用程序进行了升级。但是对于另一些行业,如信用卡、银行、购物和游戏公司,升级时的停机时间是他们不能接受的。假设eBay和PayPal对系统升级一次就要花一个多小时。那损失的费用也就会迅速增长至数百万美元,这还仅仅是直接收入损失,更不用提流失的客户了。
在动态时升级应用程序需要写一些自定义代码保证这些表在群集(服务器或者示例)中保持一致性。多次测试升级情景和脚本,在不同阶段修改报告确保升级顺利进行。修改各种转换数据库步骤、作业、文档以及确保一致性是一件很枯燥的工作,但是最终在顺利进行升级时还是得到了回报,至少在用户的角度解决了问题。 -
>监控数据库镜像和复制
一般数据库管理员从架构开始,这样就造成了他们对升级过程中如何监测SQL Server不清楚。到目前为止,升级最终要的部分就是进行计划,但是很少有公司资源筹划一次完整的负载升级测试。遗憾的是,当系统在产品的重压之下,SQL Server升级中有效负载测试就开始进行了。
我们假设公司要么使用数据库镜像、复制,要么使用的是两个系统合并升级成的一个系统。我们检查一下如何监控复制以及数据库镜像保证所有的数据以有效可靠的方式进行传输……