SQL Server 2008高可用性解决方案优劣分析

在SQL Server 2008数据库中，本身就带有不少的高可用性解决方案。如可以采用故障转移群集、数据库镜像、日志传送或者复制等手段来提高数据库的高可用性。由于解决方案多了，数据库管理员不得不掌握各个解决方案的优点与缺陷，然后根据企业的实际应用来选择合适的解决方案。其实，这不仅仅是在考验解决方案的优劣性，也是在考验数据库管理员的能力。

一、数据库镜像的优劣分析。

数据库镜像是一个软件解决方案，可以提供几乎是瞬时的故障转移，以提高数据库的可用性。简单的说，数据库镜像解决方案就是设置多个数据库，在多个数据库之间进行数据多同步。不同在同一个时间内，只有一个生产数据库(或者叫做主体数据库)，而其他数据库都是备用数据库(又叫做镜像数据库)。当主体数据库出现故障时，系统会自动切换到镜像数据库上。此时这个镜像数据库就变为了主体数据库。由于主体数据库与镜像数据库之间数据进行了实时的同步，所以对于用户访问来说，基本不受影响。

镜像服务器解决方案更大的优点就是可以提供几乎是瞬时的故障转移。不过所采用的数据库镜像的方案不同，对于这个“瞬时”的影响也是不同的。数据库镜像可以具体分为高安全模式与高性能模式。在高安全模式下，主要体现“安全”两个字，已提交的事务会交给伙伴双方提交，此时虽然比较安全，大那时会延长事务滞后的时间。而在高性能模式下，事务部需要等待镜像服务器将日志写入到硬盘中便可以提交，为此可以更大程度的提高数据库数据不同的性能。

不过这个解决方案也有一定的缺陷，最主要是其限制条件比较多。如只能够使用标准服务器;只能够使用数据库快照对镜像服务器进行有限的报告;只能够使用数据库单一、重复的副本。假如需要其他的副本的话，在可以在使用数据库镜像的同时，采用数据库的日志传送功能。可见几个不同的解决方案可以一起结合使用，吸长补短，以提高数据库的性能与高可用性。

二、日志传送的优劣分析。

跟数据库镜像一样，日志传送也是数据库级别的操作。通常情况下，可以使用日志传送来维护相应生产数据库的一个或者多个备用数据库。在日志传送中，这个生产服务器叫做主数据库服务器，备份服务器叫做辅助数据库。而在数据库镜像解决方案中，这个生产服务器也叫做主数据库服务器，不过这个辅助数据库则叫做镜像数据库。虽然他们的名字相同，但是实际上代表着同一种含义。日志传送配置包括一个主服务器(包含主数据库)，一个或多个辅助服务器(每个服务器包含一个辅助数据库)和一个监视服务器。每个辅助服务器从主数据库的日志备份按设置的时间间隔更新其辅助数据库。日志传送涉及到主服务器创建主数据库日志备份和辅助服务器还原日志备份之间用户可修改的延迟。发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。

日志传送的优势也很明显，如更大的优势可以根据需要来定义数据同步的时间，如可以将延迟的时间定义为从主服务器备份主数据库日志到辅助服务器必须还原日志备份之间的时间。在某些特定的应用环境中，这个特性会非常的有用。而且，针对单个主数据库可以在多个服务器实例上支持多个辅助数据库等等。

不过在有些情况下，这个日志传送解决方案往往不单独使用。例如将日志传送解决方案与数据库镜像结合使用。如此的话，这两个解决方案就能够各自发挥彼此的优势，以实现互补的目的。如日志传送具有支持多个备用数据库的灵活性。假如需要多个备用数据库，可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时，当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。

三、故障转移群集的优劣分析。

故障转移群集由具有两个或多个共享硬盘的一个或多个节点或服务器组成。各应用程序将安装到一个称为资源组的群集服务群集组中。在任何时候，每个资源组都仅属于群集中的一个节点。该应用程序服务具有一个与节点名称无关的虚拟名称，称为故障转移群集实例名称。应用程序可以通过引用故障转移群集实例名称与故障转移群集实例连接。应用程序不必知道哪一节点承载该故障转移群集实例。跟上面两个解决方案相比，这个故障转移群集解决方案可以说是一个基于硬件的解决方案。

故障转移群集解决方案也有不少的限制条件。有些限制条件跟数据库镜像的解决方案是相同的。如两个方案都只能够利用数据库的单个副本;需要在服务器实例范围内进行方案的实施(在镜像解决方案中比较确切的说法是需要在服务器作用范围内进行实施)。另外对于股指群集解决方案中，还有另外的一些限制。如是因为基于硬件的解决方案，为此对于硬件有比较特殊的要求，如要求硬件必须是签名的硬件等等;另外也不能够防止磁盘故障等等。其次就是在报告功能上的限制。由于故障转移群集不致此后备用部分的报告功能，这或多或少让一些数据库管理员感到遗憾。

不过与其他解决方案相比，这个故障转移群集也有很大的优势。如具有自动监测和故障转移的特性。如在当前节点不可用时，这个解决方案可以自动监测到这种故障，并可以自动在节点之间进行故障转移。假设在发生操作系统故障、非磁盘硬件故障或者对操作系统或者数据库系统进行升级时，可以在故障转移群集的一个节点上配置 SQL Server 实例，使其故障转移到磁盘组中的任意其他节点。不仅可以自动监测和故障转移，有时候出于特定的目的，还可以进行手动故障转移。如对数据库服务器进行升级时，可以手动的启动另外一个节点等等。另外最重要的一点就是可以透明客户端重定向。

复制解决方案的优劣分析。

在SQLServer数据库中，复制也是提高可用性的一个常用的解决方案。复制使用发布-订阅模式。这样，主服务器(称为发布服务器)便可向一个或多个辅助服务器(即订阅服务器)分发数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选，以便为订阅服务器提供数据子集，同时还支持分区更新。订阅服务器处于联机状态，并且可用于报告或其他功能，而无需进行查询恢复。SQL Server 提供三种复制类型：快照复制、事务复制以及合并复制。这里需要注意一点，在写项目文档的时候，需要注意不同解决方案中对于主服务器与备份服务器的称呼都是不同的。假如数据库管理员在 *** 文档时发生张冠李戴的情况，虽然他们只是叫法不同，其代表的含义基本上相同。

笔者认为，采用复制这个解决方案，相比其他方案来说，主要的优势有两个。一个是可以实现数据刷选，即可以决定在订阅服务器中保存发布服务器中的哪些数据。订阅服务器可以使发布服务器的子集，包含其部分数据，而不是全部数据。数据同步的效率就会比较高，因为可能不需要对全部数据进行同步。另外一个优势就是复制这个解决方案，数据滞后的时间最短，即数据同步最及时。