随着表的逐渐增长，您可能会预料到性能会降低，特别是在涉及到表扫描操作时。当行数达到数百万或数十亿时，传统的解决方案会使用已分区视图，这种视图由若干具有相同结构、使用 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 实现，您需要确信您的服务器始终处于可用状态。服务器群集会帮助确保您的服务器始终可用。本文提供了一些来之不易的技巧，以帮助您入门。您可以在“群集资源”边栏中找到更多有用信息。
文章来源于领测软件测试网 https://www.ltesting.net/
