计划SQL Server的合并是一项巨大的任务。你可以通过把它分割成几个独立的组件来简化这个项目，下面我将在这篇步骤指南中详细描述。

　　这些信息摘自我们最初的专家电子书《合并SQL Servers，获得可用性、可测量性和成本的节省》中的第二章《计划你的SQL Server 合并》。这一章内容解释了合并的5个步骤，以其其它一些关键的合并思考。

　　如何合并SQL Servers

　　主页: 简介

　　步骤1: 创建 SQL Server 合并方法

　　步骤 2: 分析候选的数据库、服务器等更多内容

　　步骤 3: 测试你的合并

　　步骤 4: 部署合并的SQL Server

　　步骤 5: 监控并稳定合并的SQL Servers

　　步骤1：创建SQL Server合并方法

　　要在企业范围内执行一次成功的SQL Server合并，你必须首先为你的合并团队和客户，用户数据库的业务拥有者设定目标。这些目标在很大程度上依赖于你的合并方式：在虚拟机上合并，堆叠SQL Server环境，使用存储区域网络(SAN)等。

　　合并团队事先与客户就实际的服务级别达成协议是至关重要的。这些服务级别协议不仅仅是为可用性、技术支持、变更控制和监控设定期望值，还有性能。一个设定了可支持的期望的服务级别协议可以在未来很长一段时间内建立合并努力的信心。

　　关键任务的应用程序应该标识出来。他们的服务级别协议要比其它的服务级别协议更强，它们需要这些应用程序要么不被合并，要么就经过仔细的计划进行替代，以保证在经过合并的环境中，服务级别协议可以被满足，或者超越。标准需要被应用，这些应用程序需要在合并团队的拥有和控制之下拿出来。

　　另外一个需要事先协商的服务级别协议就是要避免规模的蔓延，在这个协议中，你的合并团队必须要解决超出预期的性能问题，并且加强功能性。

　　你的团队必须考虑服务级别协议工作的各种各样的场景。例如，一些人可能在标识那些非常适合合并的候选数据库时发现一些性能很糟糕的应用程序。理想的客户会被要求取回这些应用程序进行优化。如果你的团队选择优化，你就必须负责所有的性能问题，或者在未来发生的bug。明智的选择就是仅仅标识，然后返回这些数据库给业务的拥有者，并且在服务级别协议中特别指明这一点。

　　如果业务单元不愿意或者不能返工并且优化这些SQL Server，那么尽可能地将其移植到你的数据中心，加强标准，但是不要把这些数据库与其它的SQL Server合并。合并一个性能糟糕的用户数据库可能会降低发SQL Server上所有其它用户数据库的性能。

　　一旦服务级别协议确定下来，你的合并团队就可以创建一个时间表来将企业范围的计划打碎成一个一个阶段。

　　第一个阶段就是那些最简单的用户数据库部分。这可以让团队的成员在卷入更加复杂的合并情况之前有个练习的机会。这种分阶段的方式也可以教会他们更加熟悉在合并的SQL Server之间，用户数据库在数据库负载随着时间变化的各种窍门。例如，当某个用户数据库增长的时候，它会降低合并的SQL Server上所有用户数据库的性能。另一方面，当某个应用程序的生命周期到达终点的时候，用户数据库的资源需求可能会下降，这时就可以让它转移到马力较低的服务器上去。

　　应该创建测试脚本来帮助调查现有的SQL Server应用程序。这可以让团队成员熟悉性能监控和SQL Server Profiler来捕捉和重放代表性的负载，并且监控合并解决方案。

　　合并团队还应该分工为专门的小组来简化监控和合并的解决方案。

　　一旦合并团队的成员理解了他们各自的任务，并且准备好合并了，那么下一步就是分析。

安装SQL Server 2005实例环境图解 SQL Server查询处理器机制与结构（下）

评论 (0) All