升级SQL Server
升级SQL Server的群集实例不是因为胆小：构建群集只为一个原因 - 您需要正常运行时间。但SQL Server 2005提供了许多您想利用的增强功能。所以，如果您准备升级，无需太多停机时间便可以继续进行。
您会选择哪种方案？我们首先看一看成本最高的解决方案：创建整个新群集。这意味着要创建若干新服务器，或许还要创建新的存储区域网络(SAN)。您或许可以保留现有的网络交换机，但这大约就是您所要保留的全部。显然，这种方法的成本很高，但它具有一定的优势。与旧硬件相比，新硬件的运行通常要好得多，因为磁盘容量和速度都得到了增长。因此，仅仅使用新硬件，您的性能就会得到迅速提高。您甚至可能会租用设备，而这只是为了保持领先地位。
硬件到位后，您可以在此安装上创建新的虚拟SQL Server，将生产数据库复制过来，然后考察新系统的性能，从而在移交日期之前留有充足的时间来解决程序错误。但别忘了编写脚本，从现有服务器中退出。（万一发生灾难性故障，最好访问support.microsoft.com/kb/246133来更新登录构建脚本。）
为了将停机时间减到最少，您很可能必须使用日志传送，除非您的数据库相当小并且在一段时间内没有用户建立连接。在移交之前，您都可以正确执行日志传送。接着，删除这些用户，剪切并传送最后的日志，然后指向新实例上的应用程序。（有关感兴趣的日志传送替代方法，请参阅下面的数据库镜像部分。）如果使用DNS别名，您甚至可能不需要指向新实例上的应用程序，而是只需更新 DNS 别名。这种方法的优点是，如果您的迁移只进行了一部分，但必须要回退到原始状态，那您至少还有原始文件。
您还可以采用一种成本较低的方案，但需要您做更多的预先规划。一个群集可以支持多个SQL Server实例，但每个实例必须有其自己的磁盘资源。因此，在划分SAN时，请留出一个LUN，以备将来升级。要执行升级，请在此磁盘资源上安装 SQL Server 二进制文件。您可以演习一下该系统。当您准备好后，关闭当前SQL Server，将磁盘资源从旧的 SQL Server组中移出，更新依赖关系，然后使新SQL Server实例在线。连接旧实例中的数据库，然后启动并运行。（您已提早备份了所有数据，对吗？）
这就是成本较低的方法，实行这个方法需要承担一些风险。如果出现故障，您无法将数据库与新实例分离开来并放回原来位置。您的操作已简化为从备份恢复 - 这意味着需要很长的停机时间。
还有一种方法是将两个SQL Server实例都放在您的SAN中，前提是您有足够的磁盘空间。将生产备份（和日志传送）恢复为新实例，然后按前面介绍的步骤继续进行。但现在您有退路了。而且，一旦完成迁移，您还可以释放旧实例占用的SAN资源。您只需增加额外的磁盘。
负载平衡
让我们首先揭穿这样一个常见误解。MSCS群集是用于获得高可用性的，而非用于实现负载平衡。此外，SQL Server没有任何内置的、自动负载平衡功能。您必须通过应用程序的物理设计来实现负载平衡。这意味着什么？
随着表的逐渐增长，您可能会预料到性能会降低，特别是在涉及到表扫描操作时。当行数达到数百万或数十亿时，传统的解决方案会使用已分区视图，这种视图由若干具有相同结构、使用 union ALL 挂接在一起的表组成。此外，还会在适当位置放置 CHECK 约束来区分这些成员表，而这会阻止跨已分区视图复制数据。如果在 CHECK 约束中使用的列也是主键的一部分，则该视图是可更新的。
如果成员表在其自己的文件组中，则如果这些文件组中的文件分别位于不同的物理驱动器上，那么您会获得更佳的磁盘性能。这些表甚至也可以位于不同的数据库中。但是，在SQL Server 2005 中，只要所有数据均在同一个数据库中，您就可以使用表分区，而表分区实现起来就容易得多了。
但是，假设您已经尽可能地利用了表分区或（本地）已分区视图，但性能仍然很低。如果您拥有SQL Server 2000 或SQL Server 2005，就可以利用分布式已分区视图了。主要差别在于，成员表可以位于不同的 SQL Server 实例上，而且这些实例可以安装在 N+1 群集上。为什么鼓励您这样做？如果已分区视图中的任何一个成员表转入离线状态，则整个视图也将转入离线状态。使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性。
您真的需要群集吗？
或许您有一些备用服务器无事可做，但这些服务器不在 Windows 目录的群集部分中。如果您在这些服务器可用的情况下，只是为了支持群集就必须出去购置新服务器，那么这是一种浪费可耻的行为。
数据库镜像可能是最适合替代群集的一种方法。镜像涉及到三个元素：存储镜像数据库的实例称为主体；备份服务器称为镜像；如果要实现自动故障转移，还需要第三台服务器，称为见证方。简而言之，主体上的数据库中的事务会在镜像中再次运行。当主体出现故障时，如果有见证方，数据库会自动故障转移到镜像。您必须为每个应用程序数据库设置镜像，但不能镜像系统数据库。
镜像是单独的SQL Server 实例，与群集不同的是，镜像可以位于几千英里以外。其高速缓存中填充的是由于从主体中复制事务而发生的更新活动。当然，还可以假设，除了从主体接收镜像事务之外，镜像上没有其他活动。既然 SQL Server 已经在镜像中运行，所以，故障转移的速度通常要比在群集中快。由于至少有部分高速缓存已准备好，所以，初始性能并不像在群集方案中那样低。另请注意，当镜像数据库发生故障转移时，主体和镜像会互换角色。
数据库镜像的不足之处是，需要的总磁盘容量是群集的两倍。如果您想在同步模式下运行且不想丢失任何数据，那么您还会需要更多的 CPU 处理能力。正如我所说的，要想实现高可用性，需要花费很高的成本。
组合方法
由于镜像与主体之间的距离可以相当遥远，所以对于灾难恢复 (DR) 计划来说，选择镜像是非常明智的。群集是您的第一道防线。但是，如果您要同时利用群集和镜像，那会出现什么情况呢？在群集故障转移中，如果您的镜像配置中有见证方，则当群集 SQL Server 转入在线状态时，镜像会成为主体。但是，请注意，从新主体回到（群集的）新镜像的故障转移不是自动进行的。因此，当与群集结合使用时，最好不要对您的镜像数据库启用自动故障转移。
灾难恢复并不是您使用镜像的唯一原因；当您必须向主体应用服务包或修补程序时，镜像也是非常有用的。在这种情况下，您可以手动故障转移到镜像。在应用服务包或修补程序时，旧的主体服务器暂时处于离线状态，在新主体上发生的已提交事务会排队等候，等待被发送回新镜像（旧主体）。在完成服务包或修补程序的安装之后将会进行同步。最终，这两台服务器将完全处于同步状态。现在您便可以在主体和镜像之间转换角色了。故障转移与恢复只需要几秒钟的停机时间。您可以使用这种方法将 SQL Server 迁移到另一台计算机。只是不能实现故障恢复。
虚拟服务器添加灵活性
虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统。虚拟化软件为群集概念添加了另外一层功能，因为您可以将软件加入群集。因此，如果主机正在其上运行的服务器出现故障，则主机及其来宾 OS 会故障转移到备份节点。这可能是迁移来宾服务器的最简便方法。补充一点，来宾 OS 不必具有群集功能。因此，您可以在运行于某群集中的 Microsoft Virtual Server 2005 之上的来宾 Windows Server 2003 内部运行 SQL Server Workgroup Edition。实质上，您会间接拥有群集 Workgroup Edition。
在控制之下
如果您在负责 SQL Server 实现，您需要确信您的服务器始终处于可用状态。服务器群集会帮助确保您的服务器始终可用。本文提供了一些来之不易的技巧，以帮助您入门。您可以在“群集资源”边栏中找到更多有用信息。
编辑：梦想家