第2章 选择必要的高可用性和灾难恢复技术 31
2.1 什么是SQL Server的“高可用性”与“灾难恢复” 31
2.1.1. 高可用性focuses on 数据库系统或数据库服务
2.1.2. 灾难恢复focuses on 数据库中的数据
2.2. SQL Server故障转移群集 33
2.2.1. Windows故障转移群集 33
2.2.2. SQL Server故障转移群集 36
·
将SQL Server安装成群集模式即部署在Windows群集中的多个节点上，然后组成一个虚拟的SQL Server实例。
·
安装成功以后，打开Windows的故障转移群集管理器（Failover Cluster
Manager），然后使用Windows群集的虚拟网络名来连接群集。
·
在Services and
applications下，会列出该Windows群集的所有“资源组”。所有的故障转移都是以资源组为单位发生的，在任何时候，每个资源组都仅属于群集中的一个节点，这个节点就是该资源组的“活跃节点”。可以简单地把资源组想象成在虚拟服务器上运行的一个个独立的应用程序或者服务。SQL Server资源组就是一个资源组例子。
·
SQL Server资源组包含以下资源：
o
SQL Server网络名和SQL Server IP地址
o
SQL Server和SQL
Server Agent
o
共享磁盘 - 对于一个SQL Server群集实例，数据库的所有数据文件和事务日志文件（MDF，NDF和LDF），SQL Server和SQL Server Agent的日志文件（ERRORLOG），以及一些其它的文件和目录，都是保存在共享磁盘上的。必须设置共享磁盘和SQL Server资源在一个资源组里，这样就保证了运行SQL Server服务的节点一定能访问到共享磁盘里的数据。
o
其它： (1) File Share：如果 SQL Server要使用File Stream，(2) Analysis Services：这个资源和SQL Server/SQL Server Agent资源不同，是属于Generic Service资源。
·
集群资源的配置 - Properties
o
SQL Server资源的Dependencies属性页 - SQL Server要依赖的资源包括：
ü 虚拟网络名资源
ü 共享磁盘资源
o
SQL Server资源组中属性的依赖关系 - 一个资源所依赖的其它资源必须要和这个资源处于同一个资源组里，跨资源组的依赖关系是不存在的。如果用户需要SQL Server群集实例同时可以访问多个共享磁盘资源，必须在SQL Server资源组里添加，然后让SQL Server资源去依赖于它们。没有这样的依赖关系，SQL Server群集实例将无法看到或者使用这些磁盘。
o
SQL Server资源的Policies属性页
- 这个选项卡里的选项决定了该资源发生故障转移时的行为。推荐的设置:
Ø 对于SQL Server资源组里的SQL Server资源, 共享磁盘资源, 虚拟IP地址资源, 虚拟服务名资源都建议在策略选项卡里保留其默认设置。即确保If resource fails, attempt restart on current node 被选中并选择If restart is
unsuccessful, fail over all resources in this service or application。这样的设置下，上面的资源如果因为软件或硬件故障进入失败状态，会在15分钟内尝试在当前节点重启（一般就是立刻尝试重启，不需要等15分钟那么长），第一次尝试重启失败的话，就会将整个资源组故障转移到另外的节点上。这样的设置被称为“affect the group”。
Ø 出于最大化高可用的目的，对SQL Server Agent资源, File Share资源, Analysis Services资源都建议设置为选择 If resource fails, attempt restart on current node选项，并且不选择If restart is
unsuccessful, failover all resources in this service or application 选项。这样设置下，上述资源如果由于软硬件异常进入失败状态，并不会导致整个资源组的切换，这些资源不会“affect the group”。对于这些不是非常关键的资源，通常都建议配置成不“affect the group”，这样可以消除那些不必要的故障切换发生，提高数据库服务器的在线时间。
·
SQL Server资源的Advanced Policies属性页
o
该选项卡中的“possible owners”部分会列出该资源可以切换到哪些节点上运行。SQL Server资源可以在Node1或者Node2上。
o
在这个选项卡里还有两个重要的选项。一个是“Basic resource health check interval”，另外一个是“Thorough resource health check interval”。Windows Cluster为了每个资源是否工作正常，会使用不同的时间间隔来做的两种不同程度的检查。我们通常把Basic resource health check俗称为“looks alive check”，而把Thorough resource health check称为“is alive check”。
2.2.3. SQL Server群集什么时候会发生“故障转移” 40
要了解SQL Server群集什么情况下会故障转移，就要了解sqsrvres.dll是怎么定义looksalive和isalive方法的。在安装SQL Server的时候，会安装两个SQL Server自己的resource dll ：sqsrvres.dll和sqagtres.dll，它们分别服务于SQL Server资源和SQL Server Agent资源。一般只会把SQL Server资源配置成affect the group模式。从SQL Server 2000到SQL Server 2008 R2，sqsrvres.dll中定义的looksalive和isalive方法都是类似的。
2.2.4. SQL Server群集的拓扑结构 43
·
“活跃/非活跃”群集 － 这种结构下群集有2个节点，用户在群集上安装一个SQL Server群集实例，该实例的“可能的所有者”（possible owners）包含上述两个节点。这样任意时间只有一个节点上有SQL Server服务在运行，而另一个节点就是“非活跃”节点。这种配置的优点是结构简单明了，无论SQL Server运行在哪个节点上都能获得同样的性能表现。缺点是总有一个节点处于空闲状态，浪费了50%的硬件资源。
·
“活跃/活跃”群集 － 这这种结构下用户在群集上安装两个SQL Server群集实例，每个实例的“可能的所有者”都包含群集两个节点。在正常情况下，两个实例分别运行在不同的节点上。这样两个节点就都是“活跃”节点。这种结构的优势是两个节点的硬件资源都能被充分利用，节约成本。缺点是，一旦某个节点发生故障转移，就会发生另一个节点上同时运行了两个SQL Server实例的情况。此时，这两个实例可能会争用这个节点上的CPU，内存，I/O等资源，导致两个实例的性能都受到影响。有时候可能两边的用户都不能接受。
·
N +１群集 － 即N个活跃节点加上1个非活跃节点。以3个节点的群集为例，在上面安装两个SQL Server群集实例，每个实例的possible owner包含群集中的两个节点，但是只有一个节点是两个实例共有的。在正常情况下，两个SQL Server都运行在非共有的那个节点上，互不干涉。一旦某个节点发生故障转移，就会切换到那个共有的非活跃节点上。这个结构是一个介于“活跃/非活跃”和“活跃/活跃”之间的一种方案。相对于“活跃/非活跃”，它浪费的节点资源比较少（1/N+1）。另外，两个以上的节点同时发生故障转移，需要同时切换到共有节点的概率是比较低的，因此也在一定程度上解决了“活跃/活跃”结构的性能问题。
2.2.5. sql 2012对故障转移群集的改进 44
·
多子网群集的支持－从Windows Server 2008开始，故障转移群集开始支持所谓“多站点（multi-site）群集”。也就是说，组成一个群集的节点可以被安置在相隔很远的不同的站点。此外，不同站点可以处于不同的子网，因此多子网（multi-subnet）群集也得以实现 （Windows Server 2008 R2和SQL
Server 2012）。
·
RegisterAllProvidersIP － 多子网的SQL Server情况下，一个虚拟网络名一般对应多个IP地址，而只有其中一个IP地址资源是上线状态的。那么在DNS上到底是只注册了那个上线的IP地址，还是全部IP地址都注册了呢？这取决于“虚拟网络名”资源的一个私有属性，叫做RegisterAllProvidersIP。如果RegisterAllProvidersIP被设置为0，那么只有上线的IP地址会被注册到DNS上，网络名也只会被解析到上线的IP地址。如果默认值设置为1。也就是说默认情况下，无论这个IP地址处于什么状态，多子网的群集依旧会在DNS 服务器上注册虚拟网络名到所有IP地址之间的解析关系。当客户端应用要使用虚拟网络名来连接SQL Server的时候，它会从 DNS 服务器检索所有已注册的IP 地址，并尝试连接到这些地址。这样，多子网SQL Server群集中的客户端恢复连接的时间不再受DNS 更新延迟的影响。默认情况下，客户端会按顺序去尝试DNS上所有IP 地址。 当客户端在其连接字符串中使用MultiSubnetFailover=True 参数时，客户端会改为并行地尝试所有IP 地址，并使用第一台响应它的IP地址来连接SQL Server服务器。这样的机制有助于在发生故障转移时最大程度地减少客户端恢复连接的延迟。
o
SQL Server 2005 以前版本的SQL Server 故障转移群集，数据库的所有数据文件和日志文件都必须被放在共享磁盘上，包括用户数据库和系统数据库。
o
SQL Server 2008和SQL Server 2008 R2将系统资源数据库（resource DB）与其它的系统数据库分隔开来，单独存放在了每个实例对应的Binn目录下，和其它的SQL Server可执行文件和DLL文件放在了一起。
o
从SQL Server 2012开始，除resource数据库以外的所有系统数据库（master，msdb，model和tempdb）及用户数据库不但可以被存放在共享磁盘中，也可以被存放在共享文件夹中。
o
SQL Server 2012群集的另一个变化是tempdb存放的位置。之前版本的SQL Server群集，要将所有用户数据库和系统数据库，包括tempdb，都保存在共享磁盘上。SQL Server 2012群集允许用户在安装时将tempdb的存放位置设置在本地磁盘上。这样当SQL Server资源组在某个节点上线时，就会在该节点的本地磁盘上创建新的tempdb的数据文件和日志文件。除了tempdb和资源数据库以外的其它数据库依旧存放在共享磁盘或SMB文件共享上。
o
新的ResourceDLL－SQL Server 2012群集使用了全新的Resource DLL（名字依旧是sqsrvres.dll）。新的Resource DLL中，Looksalive检查基本保持了其原有的功能，但是Isalive检查方式发生了变化。新的Isalive不仅依赖检查群集服务和SQL Server之间的连通性来判断SQL Server的健康状况，它还依赖SQL Server内部进行自我诊断，并将诊断结果报告给Resource DLL。
o
SP_SERVER_DIAGNOSTICS － Captures
diagnostic data and health information about SQL Server to detect potential
failures. The procedure runs in repeat mode and sends results
periodically. It can be invoked from either a regular or a DAC connection. It
is not necessary for failover cluster, but SQL Server runs
sp_server_diagnostics in repeat mode to periodically report the health status
of the SQL Server components to the resource DLL.
sp_server_diagnostics [@repeat_interval =]
'repeat_interval_in_seconds'
sp_server_diagnostics returns the following information
/*It is the best practice to use the extended sessions to capture the health information and save it to a file that is located outside of SQL Server. Therefore, you can still access it if there is a failure.The following example saves the output from an event session to a file*/
CREATE EVENT
SESSION [diag]
ON SERVER
ADD EVENT
[sp_server_diagnostics_component_result] (set collect_data=1)
ADD TARGET
[asynchronous_file_target] (set filename='c:\temp\diag.xel')
GO
ALTER EVENT
SESSION [diag]
ON SERVER STATE = start
GO
--The example query below reads the
extended session log file:
SELECT
xml_data.value('(/event/@name)[1]','varchar(max)') AS Name
, xml_data.value('(/event/@package)[1]', 'varchar(max)') AS Package
, xml_data.value('(/event/@timestamp)[1]', 'datetime') AS 'Time'
, xml_data.value('(/event/data[@name=''component_type'']/value)[1]','sysname') AS Sysname
, xml_data.value('(/event/data[@name=''component_name'']/value)[1]','sysname') AS Component
, xml_data.value('(/event/data[@name=''state'']/value)[1]','int') AS State
, xml_data.value('(/event/data[@name=''state_desc'']/value)[1]','sysname') AS State_desc
, xml_data.query('(/event/data[@name="data"]/value/*)') AS Data
FROM
(
SELECT
object_name as event
,CONVERT(xml,
event_data) as
xml_data
FROM
sys.fn_xe_file_target_read_file('C:\Program Files\Microsoft SQL
Server\MSSQL12.MSSQL SERVER\MSSQL\Log\*.xel',
NULL, NULL, NULL)
)
AS XEventData
ORDER BY
time;
2.2.6. 故障转移群集的故障排查 – 2个重点：有否SQL Server资源无法上线？Windows群集服务是否可以成功连接SQL Server？
·
SQL Server资源无法上线排查顺序：
o
1）在故障转移群集管理器中，确保SQL Server资源所依赖的资源都可以上线。如有错误，去Windows事件日志中去查看是否有对应的错误和警告信息，然后做进一步的排查。
o
2）如果所有依赖资源都可以上线，那么到当前节点的本地磁盘中找到SQL Server实例的Binn目录下的sqlservr.exe文件。然后看能否用命令行启动SQL Server。
o
3）如果SQL Server可以通过命令行启动起来，就说明问题出在Windows群集连接SQL Server并执行sp_server_diagnostics的过程中。这个时候可以先使用Sqlcmd等工具来连接通过命令行模式启动起来的SQL Server（记得要使用Windows验证）。如果出现连接错误或者认证错误，那么问题就转换成了一个纯粹的连接认证问题。
o
4) 如果sqlcmd可以成功连接，那么问题很可能与Kerberos / NTLM认证方式有关系。
·
SQL Server意外发生故障切换。
o
需要去分析故障转移的根本原因。需要收集以下信息：
ü Windows群集的日志，
ü SQL Server的错误日志，
ü Windows事务日志，
ü “SQLDIAG”的扩展事件（extended events）日志 (for SQL Server 2012)。
2.3. 日志传送 58
2.3.1. 日志传送的结构 59 – via log backup and restore
·
Primary
·
Secondary
·
Monitor
2.3.2. 日志传送的工作机制 60 – using sqllogship.exe for backup, copy, and restore
starting from 2005+
·
Backup job – backup
the log and send the log files to a shared folder
·
Copy job – running on the secondary
server, copying the log files in the shared folder to local folder on the
secondary server.
·
Restore job
·
Alert job – on the monitor server if
there is one, otherwise, an alert job is on both primary and secondary servers.
2.3.3. 日志传送作业的执行间隔 64 – default 15 minutes, minimum 10s
2.3.4. 日志传送的故障转移 65
- 备份主数据库的尾日志（如果可能的话）
- 把主服务器的共享目录中所有未被复制的备份文件，连同尾日志备份，复制到所有辅助服务器上日志传送所用的本地目录中
- 将所有未还原的事务日志备份按顺序还原到所有辅助数据库
- 然后删除辅助服务器上的复制作业和还原作业
- 由于日志传送只同步用户数据库的内容，但不会同步保存在master数据库中的登录信息。要使得应用可以使用新的主数据库，你需要手动把登录信息从原始的主服务器实例迁移到新的主服务器实例上。在新的主服务器上建立登录，除了要保证登录名和密码要和原始的主服务器一致之外，还要保证登录名对应的SID也一致；否则该登录名就无法被正确映射成为新的主数据库中的用户，导致应用依旧无法使用数据库。要正确的迁移登录信息，建议参照以下文章提供的方法。
- How to transfer the logins and thepasswords between instances of SQL Server 2005 and SQL Server 2008 (http://support.microsoft.com/kb/918992)
- 最后你需要通过修改连接字符串，使用别名等方法把应用重定向到新的主服务器上。
- 恢复辅助数据库之后，它就成为了新的主数据库。当故障服务器（原先的主服务器）修复后，你可以重新配置日志传送，让原先的辅助数据库开始扮演主数据库的角色，而原先故障的主数据库转为扮演辅助数据库。
o
如果原先的主数据库已经完全不可用，就必须完全重建日志传送，在重建时把原先的主服务器选择为新的辅助服务器。
o
如果原先的主数据库还可以访问，只需执行以下步骤就可以比较快速地交换主数据库和辅助数据库的角色:
ü
确保已经使用了with norecovery备份过了原始主数据库上的尾日志。
ü
删除原先的主服务器上的日志传送备份作业以及原先的辅助服务器（现在的主服务器）上的复制和还原作业。
ü
使用 SSMS 在原始的辅助数据库（要用作新的主数据库的数据库）上配置日志传送。注意，在“Initialize Secondary Database”对话框中，选中“No, the secondary database is
initialized”。
2.3.5. 日志传送的监控和故障排查 68
·
监控
o
使用SSMS中的报表。报表|标准报表|事务日志传送状态。在辅助服务器端，除了日志传送的状态外，还能看到复制作业和还原作业的信息如最后一个被复制的日志备份文件和最后一个被还原的日志备份文件。
o
直接在master数据库中 EXEC sp_help_log_shipping_monitor也能获得同样的信息。
·
故障排查
o
Find the errors
ü
查看那4个作业的历史信息（GUI或T-SQL）
o
Common problems
ü
备份作业出现问题 -把它当做一个单纯的备份失败问题进行处理
ü
复制作业相关的问题：（1）权限问题 - SQL Server Agent启动账号没有权限访问存放日志备份的共享目录；或者无法写入辅助服务器上的本地目录。(2) 共享目录不存在。(3) 日志备份文件名被人为修改了。
ü
原作业相关的问题：
（1）还原作业无法访问日志备份文件，因为该文件正在被其它进程使用。可以使用Process Explorer工具来查看是什么进程正在使用日志备份文件。（2）还原作业没有权限读取本地目录中的日志备份文件。（3）日志备份文件损坏无法还原。您可以尝试手动把该日志 备份文件从主服务器再次复制到辅助服务器上，然后运行一个restore命令来还原这个日志备份。如果依然还是得到同样的错误，那说明那个日志备份文件本身已经发生了损坏。这时别无选择，只能重建日志传送。（4）日志备份文件的LSN不在允许还原的范围内。不行的话就重建。
o
Best Practices
ü
对于启用日志传送的数据库，任何手动的日志备份都会破坏日志传送的工作。
ü
对已经启用了日志传送任务的数据库，你可以在维护计划中执行完整数据库备份和差异数据库备份, 但不能在维护计划中创建事务日志备份。
2.4. 数据库镜像 71
2.4.1. 数据库镜像的基本概念 71
·
Principal database/server
·
Mirror database/server
·
Witness server
·
Session - 通过对话，两个数据库互相进行通信和协作
·
Endpoint
·
那主体数据库和镜像数据库是如何同步数据的呢？- 2个线程。主体服务器在将主体数据库的日志从日志缓存固化到磁盘的同时，还会使用另一个线程来将日志块发送到镜像服务器的端点è日志缓存里è日志固化到磁盘上è最终更新数据页面。
·
How different from log shipping? 数据库镜像技术和日志传送一样，其同步的信息也是日志记录，而不是T-SQL命令。它们不同的是，日志传送是通过数据库日志备份和恢复。而数据库镜像更“直接”，它能够直接读取和标记日志文件里的日志记录。所以镜像技术的实时性会更好。
2.4.2. 数据库镜像操作模式 74 -高可用、高保护和高性能。
2.4.3. 客户端连接重定向及超时控制 78
·
ADO.NET和SQL Native Client这两个数据库驱动程序添加了一项特性：你可以在连接字符串中指定首选的服务器，同时也可以指定故障切换后的备选数据库。驱动程序就会遵循“连接重试算法”。当应用程序成功无法连接到当时主体服务器后，就会去尝试连接故障转移伙伴。如果成功连接，那么就会读取新的主体服务器的镜像配置信息，得到新的镜像服务器名，并缓存在应用程序的内存里。如果连接失败，那么驱动程序会继续尝试去访问Data Source中指定的首选服务器。驱动程序就会这样不断的尝试这两个服务器，直到达到了连接超时的阈值。前四轮的比例是8%, 8%, 16%,
16%, 24%, 24%, 32%, 32%。
·
对于不是ADO.NET和SQL Native Client的驱动，即使数据库是镜像数据库，在应用程序端也不会缓存故障转移伙伴的名称，同时也不支持failover partner参数，因此就必须要考虑其它的方法来实现连接重定向，比如说在应用程序的代码中加入重试和重定向的逻辑。
·
其它问题：镜像切换还有许多需要考虑的事情。举例来说，数据库镜像只能保持用户数据库中数据的同步，而系统数据库是无法配置镜像的。也就是说，登录名、SQL Server实例的配置、维护计划、作业等保存在master、msdb或 model数据库里的信息在镜像的两台服务器上并不是同步的。一旦发生故障转移，即使数据库依旧可用，应用程序可能会因为各种原因无法正常工作。
2.4.4. 数据库镜像的监控和故障排查 81
·
监控
o
在主体服务器，镜像服务器和见证服务器上SQL Server的ERRORLOG。
o
性能监视器 – SQL Server: Database
Mirroring
o
Database Mirroring Monitor
o
EXEC sp_dbmmonitorresults
·
排查
o
诊断发生故障转移的原因（对于非高可用模式的镜像，就是诊断镜像停止工作的原因）- 对于这类问题，你需要收集主体服务器，镜像服务器和见证服务器（如果有的话）上的ERRORLOG。
o
性能问题 - 由于只有主体服务器才能影响应用端的请求，性能问题都会体现在主题服务器端。但是这类问题的最终症结往往却不在主体服务器上，而在镜像服务器上或者是在网络上。要诊断这类问题，需要在主体服务器和镜像服务器上打开性能监视器来记录各项镜像相关的数据，以及磁盘、网络、内存、CPU相关的数据。此外数据库镜像监视器也能帮助你了解主体/镜像服务器的运行状态。通过这些数据，你可以了解镜像服务器的处理事务的效率，网络传送事务的速度，以及镜像端的磁盘负载和磁盘性能（往往是最大瓶颈）等情况。
2.5. 复制 84 – Not designed for disaster recovery or HA, mainly focus on
data synchronization. 事务复制最适合用于数据库对象级别的复制。事务复制的强大之处在于它可以只同步几个表，甚至是表中的部分数据，这是数据库镜像和日志传送都无法达到的功能。微软也建议只在同步比较小量数据的情况下使用事务复制作为灾难恢复方案。
2.5.1. 复制的基本概念 84
·
It uses the magazine
metaphor.
2.5.2. 复制的类型 86
·
Snapshot
replication - most appropriate when data changes are substantial but
infrequent.
o
PublicationsàSnapshot AgentàSnapshot folderàDistribution AgentàSubscription
·
Transactional
replication is typically used in server-to-server environments for
capturing DML and DDL changes on the publisher. If
you want to update data from the subscriber, you can use updatable subscription
and peer-to-peer subscription.
o
LogàLog ReaderàDistribution
DatabaseàDistribution
AgentàSubscription
o
Changes at the SubscriberàQueue Reader
Agentà
Distribution DatabaseàPublication
(for updatable subscription)
·
Merge
replication is typically used in server-to-client environments to merge updates from various nodes into a single,
uniform result.
o
DML/DDL Changes at either Publisher or
SubscriberàSystem
Tables & TriggersàMerge AgentàDistribution
DatabaseàSubscriber
or Publisher
2.5.3. 灾难恢复和复制 90
当使用事务复制来作为灾难恢复方案时，应当把主服务器选为发布服务器，把备用服务器选为订阅服务器。关于订阅模式，一般我们建议使用推送订阅，并且设置为“连续发送”，这样分发服务器会立刻将接收到的发布给发送到订阅服务器上。一旦发布数据库出了问题，订阅数据库上还有副本数据可以使用。复制的订阅服务器是可以访问的，因此你可以将一些只读的应用，如报表系统，运行在订阅服务器上，这能够分流发布数据库的负载。但是，由于数据库是用于灾难恢复的目的，你应该禁止任何人或应用更新订阅服务器上的数据。
2.6. 高可用和灾难恢复技术的选择 9
2.6.1. 高可用和灾难恢复技术的比较 91
2.6.2. 高可用和灾难恢复技术的组合 97
·
故障转移群集+日志传送
o
这个组合是在数据库镜像出现之前最常见的方案。故障转移群集提供了非常好的高可用性，但是对于数据损坏问题却非常脆弱。日志传送提供了灾难恢复的功能，但是在高可用性上很薄弱。它们两者的互补性非常强。
o
整个方案需要至少3台服务器。两台服务器用于实现故障转移群集。故障转移群集实例需要被配置为日志传送的主服务器，而第三台服务器作为日志传送的辅助服务器维护一个冗余的副本数据库。
·
故障转移群集+数据库镜像
o
由于故障转移群集+日志传送的组合在执行灾难恢复的时候可能会有一定的数据损失。从SQL Server 2005开始，你可以选择故障转移群集+数据库镜像这样的组合。数据库镜像替代日志传送，提供了数据损失更少（甚至是零损失）的灾难恢复能力；同时也可以提供更快的故障转移，提高了可用时间。
o
你有三种部署的方案:
ü 两台服务器的方案 (两个服务器配置成一个群集，在该群集上安装两个SQLServer实例，分别运行在两个节点，即所谓的活跃/活跃模式。而镜像的主体服务器在其中一个实例上运行，镜像服务器在另一个实例中运行。这个方案虽然很省硬件但是风险也很大。一旦某一个群集节点失败，就会造成镜像的主体服务器和镜像服务器运行在同一个节点上，该节点的硬件资源很可能捉襟见肘，严重影响主体服务器的性能。另外，主体服务器和镜像服务器作为一个Windows群集上的两个实例，意味它们其实是共用一个硬件存储器的。一旦这个存储器出了问题，那么主体服务器和镜像服务器上的两个数据副本就都不可用了，灾难恢复和高可用也无从谈起)。
ü 三台服务器的方案 (这个方案中，故障转移群集作为主体服务器，而镜像服务器驻留在一个单独的非群集的服务器上)。
ü 四台服务器的方案 (四台服务器分别组成两个故障转移群集，一个群集作为镜像的主体服务器实例，另一个群集作为镜像的镜像服务器实例。最佳情况下，这两个群集使用两个独立的存储器，避免存储区损坏导致整个方案失败的可能性)。
·
故障转移群集+数据库镜像+日志传送 -可靠性最高，代价是硬件成本和维护复杂度也很高。
2.7. 小结 100
