配置镜像_SQL Server 2005 镜像配置图文并茂超详细版

1. 目的

本文档将介绍SQL Server 2005 镜像配置方法及注意事项。

2. SQL Server 2005 镜像技术

2.1. 概述

"数据库镜像"是用于提高数据库可用性的主要软件解决方案。 镜像基于每个数据库实现，并且只适用于使用完整恢复模式的数据库。 简单恢复模式和大容量日志恢复模式不支持数据库镜像。 因此，所有大容量操作始终被完整地记入日志。 数据库镜像可使用任意支持的数据库兼容级别。

数据库镜像维护一个数据库的两个副本，这两个副本必须驻留在不同的 SQL Server 数据库引擎服务器实例上。 通常，这些服务器实例驻留在不同位置的计算机上。 其中一个服务器实例使数据库服务于客户端("主体服务器")， 另一个服务器实例则根据镜像会话的配置和状态，充当热备用或温备用服务器("镜像服务器")。 同步数据库镜像会话时，数据库镜像提供热备用服务器，可支持在已提交事务不丢失数据的情况下进行快速故障转移。未同步会话时，镜像服务器通常用作备用服务器(可能造成数据丢失)。

注意：不能镜像 master、msdb、tempdb 或 model 数据库。

2.2. 优点

2.2.1. 增强数据保护功能

数据库镜像提供完整或接近完整的数据冗余，具体取决于运行模式是高安全性还是高性能。

在 SQL Server 2005 Enterprise Edition 或更高版本上运行的数据库镜像伙伴会自动尝试解决某些阻止读取数据页的错误。 无法读取页的伙伴会向其他伙伴请求新副本。 如果此请求成功，则将以新副本替换不可读的页，这通常会解决该错误。

2.2.2. 提高数据库的可用性

发生灾难时，在具有自动故障转移功能的高安全性模式下，自动故障转移可快速使数据库的备用副本联机(而不会丢失数据)。在其他运行模式下，数据库管理员可以选择强制服务(可能丢失数据)，以替代数据库的备用副本。

2.2.3. 提高生产数据库在升级期间的可用性

若要尽量减少镜像服务器的停机时间，您可以按顺序升级参与数据库镜像会话的 SQL Server 实例。 这样只会导致一个故障转移的停机时间。 这种形式的升级称为"滚动升级"。

2.3. 镜像工作方式

在"数据库镜像会话"中，主体服务器和镜像服务器作为"伙伴"进行通信和协作。 两个伙伴在会话中扮演互补的角色："主体角色"和"镜像角色"。在任何给定的时间，都是一个伙伴扮演主体角色，另一个伙伴扮演镜像角色。 每个伙伴拥有其当前角色。 拥有主体角色的伙伴称为"主体服务器"(Principal)，其数据库副本为当前的主体数据库。 拥有镜像角色的伙伴称为"镜像服务器"(Mirror)，其数据库副本为当前的镜像数据库。 如果数据库镜像部署在生产环境中，则主体数据库即为"生产数据库"。

数据库镜像涉及尽快将对主体数据库执行的每项插入、更新和删除操作"重做"到镜像数据库中。重做通过将每个活动事务日志记录发送到镜像服务器来完成，这会尽快将日志记录按顺序应用到镜像数据库中。 与逻辑级别执行的复制不同，数据库镜像在物理日志记录级别执行。

2.3.1. 镜像-无见证服务器(Witness)

数据库镜像会话以同步操作或异步操作运行。 在异步操作下，事务不需要等待镜像服务器将日志写入磁盘便可提交，这样可最大程度地提高性能。 在同步操作下，事务将在伙伴双方处提交，但会延长事务滞后时间。

有两种镜像运行模式。 一种是"高安全性模式"，它支持同步操作。 在高安全性模式下，当会话开始时，镜像服务器将使镜像数据库尽快与主体数据库同步。 一旦同步了数据库，事务将在伙伴双方处提交，这会延长事务滞后时间。

第二种运行模式，即"高性能模式"，异步运行。 镜像服务器尝试与主体服务器发送的日志记录保持同步。 镜像数据库可能稍微滞后于主体数据库。 但是，数据库之间的时间间隔通常很小。 但是，如果主体服务器的工作负荷过高或镜像服务器系统的负荷过高，则时间间隔会增大。

在高性能模式中，主体服务器向镜像服务器发送日志记录之后，会立即再向客户端发送一条确认消息。 它不会等待镜像服务器的确认。这意味着事务不需要等待镜像服务器将日志写入磁盘便可提交。 此异步操作允许主体服务器在事务滞后时间最小的条件下运行，但可能会丢失某些数据。

所有数据库镜像会话都只支持一台主体服务器和一台镜像服务器。 下图显示了该配置。

2.3.2. 镜像-有见证服务器(Witness)

具有自动故障转移功能的高安全性模式要求使用第三个服务器实例，称为"见证服务器"。 与这两个伙伴不同的是，见证服务器并不能用于数据库。 见证服务器通过验证主体服务器是否已启用并运行来支持自动故障转移。只有在镜像服务器和见证服务器与主体服务器断开连接之后而保持相互连接时，镜像服务器才启动自动故障转移。

下图显示了包含见证服务器的配置。

注意：

1、使用见证服务器必须保证其和数据库镜像伙伴(主体服务器和镜像服务器的)的网络通讯畅通，否则见证服务器的故障会导致数据库镜像失败。

2、仅 SQL Server 2005 Standard Edition 及更高版本和 SQL Server 2005 Enterprise Edition 及更高版本支持数据库镜像伙伴。 SQL Server 2005 Workgroup Edition 及更高版本和 SQL Server 2005 Express Edition 及更高版本也支持见证服务器。 建立新的镜像会话需要所有涉及的服务器实例运行同一版本的 SQL Server。

2.3.3. 镜像运行方式与数据安全

如果数据要求不丢失，我们推荐"没有见证服务器的同步"方式。

如果可以容忍少量数据丢失，主服务器效率是关键。我们推荐"异步"方式。

2.4. 镜像环境中数据操作顺序

2.4.1. 无镜像时

2.4.2. 同步镜像

2.4.3. 异步镜像

3. 配置过程

我们准备了两个数据库实例：Principal和Mirror。在这两个实例上我们将演示如何通过SQL Server Management Studio配置Mirror。

3.1. 准备工作

分别在数据库实例Principal和Mirror上创建数据库MirrorDB。将备份文件分别拷贝到这两台机器上，还原数据库。建议两个数据库的物理文件路径相同。

还原Principal上的数据库：

还原mirror实例上的数据库：

注意：Mirror实例的数据库要用Restore with NORecovery。

两个实例数据库还原后的状态如下：

3.2. 配置Mirror

单击"配置安全性"弹出配置向导。

下一步

我们不使用见证服务器，下一步。

下一步

下一步

点击"连接"按钮

数据合法的身份校验信息

下一步

Principal和Mirror没有域环境，SQL Server服务都是使用的.administrator帐户。如果有域环境，建议使用对两台机器都有administrator权限的域用户。

镜像配置不成功的大部分原因是网络和安全检查无法通过。

下一步

点击完成。

关闭向导，返回主界面。

如果单击"开始镜像"按钮，SQL Server将尝试连接两台机器进行镜像。但是我们通常选择"不开始镜像"，这样我们可以选择镜像类型(同步或异步)，或选择IP地址方式设置镜像。

我们点击"不开始镜像"按钮。

我们选择了高性能的异步模式，而且主体服务器和镜像服务器是使用机器名还是IP地址都可以修改。

一切设置完毕，点击"开始镜像"按钮。

试验机没有域环境，所以不用理会这个提示。直接点"是"。

至此SQL Server 2005的镜像已经完全设置完毕了。单击"确定"完成镜像配置。

我们看到镜像已经配置成功了。

4. 监控镜像工作情况

4.1. 性能计数器

性能计数器对系统资源消耗最少，在负载较高的系统中建议使用性能计数器观察镜像性能。

4.2. 镜像监视器

SQL Server提供镜像监视器，可以利用图形工具观察镜像行为。

4.3. 系统存储过程和视图

4.3.1. 系统视图sys.dm_db_mirroring_connections

使用系统视图sys.dm_db_mirroring_connections来观察镜像配置参数。

针对为每个数据库镜像建立的连接返回一行。

4.3.2. sp_dbmmonitor系列存储过程

使用sp_dbmmonitor系列存储过程观察镜像运行期行为。注意：sp_dbmmonitor是一系列系统存储过程的统称，并不存在sp_dbmmonitor存储过程。

5. 故障切换

我们不建议使用自动故障切换镜像。自动切换需要见证服务器，见证服务器与主服务器的网络连接容易出现单一故障点。当主服务器非常繁忙时，与见证服务器的联系延迟也容易造成见证服务器认为主服务器已经shutdown，而错误的进行镜像切换。

5.1. 同步切换

镜像如果是同步模式，当主服务器(Principal)shutdown，我们在镜像服务器(Mirror)上执行下列命令：

--取消镜像关系

ALTER DATABASE MirrorDB SET PARTNER OFF

--恢复数据库

RESTORE DATABASE MirrorDB WITH RECOVERY

5.2. 异步切换

镜像如果是异步模式，当主服务器(Principal)shutdown，我们在镜像服务器(Mirror)上执行下列命令：

--强制恢复数据库

ALTER DATABASE dbname SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

请注意，这种切换方式可能会造成数据丢失。

6. 连接客户端与镜像数据库

6.1. 连接机制

对于到镜像数据库的初始连接，客户端必须提供一个至少提供服务器实例名称的连接字符串。这个必需的服务器名称应标识当前主体服务器实例，并称为"初始伙伴名称"。

另外，连接字符串还可以提供另一个服务器实例的名称，此名称应标识当前镜像服务器实例，以便在首次连接尝试期间初始伙伴不可用的情况下使用。第二个名称称为"故障转移伙伴名称"。

连接字符串还必须提供数据库名称。这是数据访问接口启用故障转移尝试所必需的。

接收连接字符串后，数据访问接口将初始伙伴名称和故障转移伙伴名称(如果提供)存储在客户端易失内存的缓存中(对于托管代码，缓存的作用域限定为应用程序域)。缓存后，数据访问接口将从不对初始伙伴名称进行更新。客户端提供故障转移伙伴名称时，数据访问接口还暂时存储此故障转移伙伴名称，以防出现访问接口无法使用初始伙伴名称进行连接的情况。

数据库镜像会话无法避免与客户端相关的服务器访问问题，例如，客户端计算机出现网络通信问题时。到镜像数据库的连接尝试也可能会因为各种与数据访问接口无关的原因而失败；例如，连接尝试可能会因为下列情况而失败：主体服务器实例处于不活动状态(如同数据库进行故障转移时发生的情况)或者网络错误。

尝试连接时，数据访问接口首先使用初始伙伴名称。如果指定的服务器实例可用并且为当前主体服务器实例，则连接尝试通常都会成功。

注意：如果镜像会话暂停，则客户端通常连接到主体服务器并下载伙伴名称。但是，在恢复镜像之前，数据库不可用于客户端。

如果此尝试失败，则数据访问接口将尝试使用故障转移伙伴名称(如果可用)。如果任一伙伴名称都正确标识了当前主体服务器，则数据访问接口通常都会成功打开初始连接。完成此连接后，数据访问接口将下载当前镜像服务器的服务器实例名称。此名称作为故障转移伙伴名称存储在缓存中，从而覆盖客户端提供的故障转移伙伴名称(如果有)。此后，SQL Server 的 .NET Framework 数据访问接口不会更新故障转移伙伴名称。相反，每当后续连接或连接重置返回不同的伙伴名称时，SQL Server Native Client 便会更新高速缓存。

下图针对名为 Db_1 的镜像数据库说明了到初始伙伴 Partner_A 的客户端连接。此图显示的情况是：客户端提供的初始伙伴名称正确标识了当前主体服务器 Partner_A。初始连接尝试成功，数据访问接口在其本地缓存中将镜像服务器(当前为 Partner_B)的名称存储为故障转移伙伴名称。最后，客户端连接到 Db_1 数据库的主体副本。

初始连接尝试可能会失败，例如，因为网络错误或不活动的服务器实例。由于初始伙伴不可用，因此要让数据访问接口尝试连接到故障转移伙伴，客户端必须在连接字符串中提供故障转移伙伴的名称。

在这种情况下，如果故障转移伙伴名称不可用，则原始连接尝试将继续，直到网络连接超时或返回错误(与非镜像数据库的情况相同)。

连接字符串中提供故障转移伙伴名称时，数据访问接口的行为取决于网络协议和客户端的操作系统，如下所示：

· 对于 TCP/IP，如果客户端运行的是 Microsoft Windows XP 或更高版本，则使用与数据库镜像相关的连接重试算法调整连接尝试。"连接重试算法"确定在给定连接尝试中为打开连接所分配的最长时间("重试时间")。

· 对于其他网络协议以及未运行 Microsoft Windows XP 或更高版本的客户端

如果发生错误或者初始伙伴不可用，则初始连接尝试将处于等待状态，直到数据访问接口上的网络连接超时期限过期或登录超时期限过期。通常，此等待时间大约为 20 至 30 秒。此后，如果数据访问接口尚未超时，则它会尝试连接到故障转移伙伴。如果连接超时期限过期而未成功连接或者故障转移伙伴不可用，则连接尝试会失败。如果故障转移伙伴在登录超时期限内可用并且现在为主体服务器，则连接尝试通常都会成功。

6.2. 镜像数据库的连接字符串

例如，为了使用 TCP/IP 显式连接到 Partner_A 或 Partner_B 中的 AdventureWorks 数据库，客户端应用程序将提供以下连接字符串：

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

另外，客户端还可以使用 IP 地址和端口号标识初始伙伴 Partner_A；例如，如果 IP 地址为 250.65.43.21，端口号为 4734，则连接字符串将为：

"Server=250.65.43.21,4734; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

7. 关于镜像的一些常见问题

7.1. 是否需要开启1400标志

在SQL Server 2005 sp1之前，镜像功能没有完全支持前，需要用户手工打开1400跟踪标志。

7.2. 镜像和群集的区别

搭建群集需要独立的磁盘阵列柜，故障转移依靠操作系统群集服务，磁盘是群集方案的单一故障点(有些群集方案为了避免这个单一故障点，需要和镜像搭配使用)。配制镜像不需要独立的磁盘阵列设备，也不存在磁盘这个单一故障点，但是因为需要进行日志传输，需要牺牲一些系统资源，镜像单机比较性能稍逊群集单机。

7.3. 镜像和复制的区别

镜像只支持两个节点之间建立，而且对两个节点间的网络条件要求更高，镜像对象是数据库。

复制支持多个节点之间传输数据，而且可以容忍一定的网络延迟，复制的对象可以是表、视图、存储过程设置单条记录。但是复制对系统资源的消耗要高于镜像。

7.4. 怎么读取镜像数据库(Mirror)数据

在镜像正常工作期间，镜像数据库(Mirror)的状态为"Recovering…"无法读取其数据。我们可以为该镜像数据库建立数据库快照，通过数据库快照可以查询快照建立时刻，镜像数据库中的数据。

7.5. 镜像后数据库性能损失多少

在日志产生量较高的环境中，同步镜像会消耗主服务器(Principal)20%-30%的系统性能，异步在3%-5%左右。更详细的数据，请参阅性能优化组的Mirror测试报告。