本文对SQL SERVER 2005数据库镜像进行了教程式的讲解，具体内容包括：介绍、动态、可用性场景、实现和高可用性技术，供大家参考！

　　概述

　　数据库镜像是SQL SERVER 2005用于提高数据库可用性的新技术。数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器，并且能够在出现故障时快速转移到备用服务器。可以编写客户端程序自动重定向连接信息，这样一旦出现故障转移就可以自动连接到备用服务器和数据库。

　　自动进行故障转移并且使数据损失最小化通常包括昂贵的硬件和复杂的软件。但是，数据库镜像可以在不丢失已提交数据的前提下进行快速故障转移，无须专门的硬件，并且易于配置和管理。

　　数据库镜像介绍

　　在数据库镜像中，一台SQL Server 2005实例连续不断的将数据库事务日志发送到另一台备用SQL Server实例的数据库副本中。发送方的数据库和服务器担当主角色，而接收方的数据库和服务器担当镜像角色。主服务器和镜像服务器必须是独立的SQL Server 2005实例。

　　在所有SQL Server数据库中，在对真正的数据页面进行修改之前，数据改变首先都记录在事务日志中。事务日志记录先被放置在内存中的数据库日志缓冲区中，然后尽快地输出到磁盘（或者被硬化）。在数据库镜像中，当主服务器将主数据库的日志缓冲区写入磁盘时，也同时将这些日志记录块发送到镜像实例。

　　当镜像服务器接收到日志记录块后，首先将日志记录放入镜像数据库的日志缓冲区，然后尽快地将它们硬化到磁盘。稍后镜像服务器会重新执行那些日志记录。由于镜像数据库重新应用了主数据库的事务日志记录，因此复制了发生在主数据库上的数据改变。

　　主服务器和镜像服务器将对方视为数据库镜像会话中的伙伴。数据库镜像会话包含了镜像伙伴服务器之间的关系。一台给定的伙伴服务器可以同时承担某个数据库的主角色和另一个数据库的镜像角色。

　　除了两台伙伴服务器（主服务器和镜像服务器），一个数据库会话中可能还包含第三台可选服务器，叫做见证服务器。见证服务器的角色就是启动自动故障转移。当数据库镜像用于高可用性时，如果主服务器突然失败了，如果镜像服务器通过见证服务器确认了主服务器的失败，那么它就自动承担主服务器角色，并且在几秒钟之内就可以向用户提供数据库服务。

　　数据库镜像中需要注意的一些重要事项：

　　◆主数据库必须为FULL还原模型。由于bulk-logged操作而导致的日志记录无法发送到镜像数据库。

　　◆初始化镜像数据库必须首先使用NORECOVERY还原主数据库，然后再按顺序还原著数据库事务日志备份。

　　◆镜像数据库和主数据库名称必须一致。

　　◆由于镜像数据库处于recovering状态，因此不能直接访问。通过在镜像数据库上创建数据库快照可以间接读取某一个时刻点的镜像数据库。（参阅该白皮书后面“数据库镜像和数据库快照”部分）

　　注意： 要想获取更多与数据库镜像术语有关的信息，请参阅SQL Server 2005 Books Online中关于“Overview of Database Mirroring”。

　　操作模式

　　数据库镜像会话有三种可能的操作模式。根据事务安全性的设置以及镜像会话中是否需要见证服务器来决定精确的操作模式。

　　表1：数据库镜像操作模式

　　如果safety设置为FULL，那么通过同步方式传输数据，并且需要一台镜像服务器才能提供数据库服务。quorum投票表决要求至少两台服务器的参与才能够决定两个伙伴服务器各自承担什么角色，主角色还是镜像角色。

　　为了更深入研究这三种操作模式，首先来更进一步研究一下事务安全性和quorum的角色。

　　事务安全性

　　If 事务安全性（或者'safety'）设置为FULL，那么主服务器和镜像服务器工作在同步传输模式下。当主服务器硬化其主数据库日志记录到磁盘时，也同时将日志发送到镜像服务器。然后主服务器等待镜像服务器的回答。镜像服务器将那些相同的日志记录硬化到镜像日志所在磁盘后，对主服务器进行答复。当safety设置为OFF时，主服务器不会等待来自服务器的确认，因此主数据库和镜像数据库可能不是完全同步的（也就是，镜像可能滞后于主数据库）。

　　同步传输方式保证镜像数据库事务日志中所有事务与主数据库事务日志中的事务同步，因此可视为事务是安全传输的。要将safety设置为FULL，使用

　　当safety设置为OFF，主服务器和镜像服务器之间的通信是异步的。主服务器不会等待镜像服务器已将事务记录硬化的确认信息。镜像服务器通过尽快记录事务日志的来试图保持与主服务器同步，但是如果主服务器突然失败同时强制镜像服务器提供服务，那么某些事务还是有可能丢失（参阅SQL Server Books中的'Forced Service'）。

　　Quorum和见证服务器

　　当safety设置为FULL，数据库镜像需要quorum才能提供数据库服务。quorum是在同步数据库镜像会话中要求的所有连接起来的服务器之间的最小关系。由于一个quorum至少需要两台服务器，因此当safety为FULL时，主服务器必须和其他某至少一台服务器组成quorum才能够提供数据库服务。

　　见证服务器帮助主服务器或者镜像服务器组成quorum。如果存在见证服务器，那么主数据库或者镜像数据库失败时，其余两台服务器还可以组成quorum。如果主服务器无法看到镜像服务器，那么它可以和见证服务器组成quorum，并保持提供数据库服务。类似地，如果镜像服务器和见证服务器看不到主服务器，那么这两台服务器可以组成quorum，镜像服务器担当新主服务器的角色。

　　见证服务器失败不被视为数据库镜像绘画中的单点失败。因为如果见证服务器失败了，那么主服务器和镜像服务器还可以组成quorum（更多信息请参阅SQL Server Books Online中的“Quorum in Database Mirroring Sessions”主题）。

　　高可用操作模式

　　高可用操作模式支持最大程度的数据库可用性，如果主数据库失败将自动转移到经销数据库。它要求将safety设置为FULL并且定义一台见证服务器作为数据库镜像会话中的一员。

　　高可用操作模式最适合于那些服务器之间具有高速且可靠的通信线路，同时要求在单一数据库上实现自动故障转移的场景。当safety为FULL时，主服务器必须短暂等待来自镜像服务器的回答，主服务器性能也因此受到镜像服务器能力的影响。由于单数据库失败将导致自动故障转移，因此如果有多数据库应用程序，那么就应该考虑其他操作模式（参阅该白皮书中实现数据库镜像部分介绍的“多数据库问题”）

　　高可用模式中数据库镜像是自监视的。如果主数据库突然不可用，或者主服务器停机，那么见证服务器和镜像服务器将组成quorum，然后镜像的SQL Server将进行自动故障转移。此时，竞相服务器实例将其角色转换为新主服务器并恢复数据库。由于镜像数据库已经重新执行了主数据库的事务日志并且其事务日志也与主数据库同步，因此镜像服务器可以快速提供数据库服务。

　　此外，SQL Server 2005可以在数据库恢复前就向用户提供数据库服务。SQL Server数据库恢复包括三个阶段：分析阶段、redo阶段、以及最后的undo阶段。在SQL Server 2005中，只要redo阶段完成，新恢复的数据库就可以让用户访问。因此如果数据库镜像故障转移发生，新恢复的主数据库只要完成了redo阶段就可以向用户提供服务了。因为镜像数据库自始至终都在重新执行事务日志记录，因此所有镜像服务器只须完成redo过程就可以了，通常几秒钟就可以完成。

　　高保护操作模式

　　高保护操作模式中事务安全性设置为FULL，但是镜像会话中没有见证服务器。主服务器必须组成quorum，可是没有见证服务器，因此只能和镜像服务器配合在一起。这种模式下由于没有见证服务器来担当平局决胜的角色，因此只能手动完成故障转移。行自动故障转移是不可能的，因为如果主服务器失败，镜像服务器没有见证服务器来组成quorum。

　　safety设置为FULL，如果主服务器突然间失去了和镜像服务器的quorum，那么镜像服务器必须使其数据库停止服务。不推荐使用高保护模式的数据库镜像配置，除非在高可用模式下必须临时移除见证服务器时，可以使用该模式作为一种临时过渡。

　　高性能操作模式

　　在高性能操作模式下，事务安全性设置为OFF，以异步方式传输日志记录。主服务器无须等待镜像服务器所有日志记录已被硬化的确认信息。镜像服务器尽自己最大可能保持与主服务器数据的一致，但不能保证在任何时刻来自主数据库的所有最新事务日志记录都能够被硬化到镜像数据库的事务日志中。

　　在高性能模式下，见证服务器不承担任何角色，也不需要quorum。因此高性能模式无法启用自动和手动的故障转移。唯一允许的故障转移方式就是forced service ，它同样也是一种手工操作：

　　forced service故障转移导致立刻恢复镜像数据库。如果某些主数据库的事务日志记录还没有被镜像服务器接收，那么恢复镜像数据库将导致潜在的数据丢失。高性能模式特别适合于远距离的数据传输（换句话说，用于远程站点的灾难恢复），或者对那些活动频繁且可以容忍某种程度数据丢失的数据库进行镜像。

　　数据库快照和数据库镜像

　　由于镜像数据库处于recovering状态，因此不可访问也不可读。在SQL Server 2005企业版和开发人员版中可以创建数据库快照来读取某个时点的镜像数据库。数据库快照提供了一个只读的数据库视图，开放数据给用户访问。这些数据与创建快照时刻的数据库数据相一致。

　　对数据库快照的访问如同访问一个其他的数据库。查询数据库快照时，从数据库快照文件中读出那些自快照创建后被修改的数据，从原始数据库中读出未修改的数据。最终效果就是读取了在创建快照时刻数据库当时的数据。（更多信息请参阅SQL Server Books Online中"Using Database Snapshots with Database Mirroring"主题。）

　　由于数据库快照确实增加了镜像服务器的负担，因此需要当心它们对数据库镜像性能可能造成的影响。由于只能镜像到一个数据库，因此如果需要将数据扩充到多个只读的报表服务器上，那么事务复制是更好的选择。（更新信息请阅读后面实现数据库镜像部分的“数据库镜像和复制”）

　　客户端重定向

　　在SQL Server 2005中，如果使用ADO.NET或者SQL Native Client连接配置了镜像的数据库，那么应用程序就可以利用驱动程序的能力在发生数据库镜像故障转移时自动重定向数据库连接。必须在连接字符串中指定原始主服务器和数据库名称，以及可选的故障转移伙伴服务器名称。

　　连接字符串的写法有许多种，以下只给出一个例子，指定server A作为主服务器，server B作为镜像服务器，AdventureWorks作为数据库名称：

　　如果连接到原始主服务器失败，那么就使用连接字符串中的failover partner作为备用服务器名称。如果连接到原始主服务器成功，那么就不使用连接字符串中的failover partner名称，但是会从主服务器上查询其故障转移伙伴的名称并将结果存放在客户端缓存中。

　　假设客户端成功连接到主服务器，然后一个数据库镜像故障转移发生（自动地、手动的、forced）。当下一次应用程序尝试使用连接时，ADO.NET或者SQL Native Client驱动程序将会检测到与旧主服务器的连接已经失败，然后自动重新连接由failover partner名称指定的新主服务器。如果连接成功并且新的镜像服务器存在，那么驱动程序从新主服务器处获取新的故障转移伙伴名称并将其存放在客户端缓存中。如果无法连接到备用服务器，那么驱动程序将交替尝试与每个服务器的连接直道连接超时。

　　使用内置在ADO.NET和SQL Native Client驱动程序中的数据库镜像支持的最大优点就是无须重新编写应用程序，或者在应用程序中编写特殊代码来处理数据库镜像的故障转移。

　　如果不使用ADO.NET或者SQL Native Client自动进行重定向，那么也可以使用其他技术使应用程序进行故障转移。例如，如果客户端连接到一台虚拟服务器，可以使用Network Load Balancing手动重定向一台服务器到另一台服务器的连接。还可以编程实现自己的重定向代码和连接重试逻辑。

　　但是，所有这些用于协调客户端重定向和数据库镜像的技术都有一些重要限制。数据库镜像只能工作在数据库级别，而不是服务器级别。如果应用程序查询一台服务器上的多个数据库，或者使用完全限定对象名称进行跨数据库查询，那么就需要多加小心了。如果多个数据库位于一台服务器并且都配置了和备用服务器的镜像，就有可能出现其中一个数据库故障转移到备用服务器而其他数据库依然在原始服务器的情况。如果是那样的话，可能就要求每个数据库查询都使用一个单独的连接，这样将无法进行跨数据库查询，因为在镜像服务器上只有一个数据库是主数据库，其余都是镜像数据库。

　　数据库镜像与SQL SERVER 2005版本

　　下表显示各种版本的SQL SERVER 2005支持的数据库镜像功能。

　　表2：数据库镜像和SQL SERVER 2005版本

　　少数几个数据库镜像功能要求使用SQL SERVER 2005企业版或者开发人员版：

　　◆高性能模式下safety设置为OFF （异步数据传输）；

　　◆数据库快照；

　　◆使用多线程在镜像数据库上应用事务日志（并行REDO）。

　　SQL Express和工作组版本可以作为数据库镜像的见证服务器，但不能作为伙伴服务器。

　　数据库镜像动态

　　要深入理解SQL SERVER 2005 数据库镜像，了解数据库镜像会话如何变化将对您大有帮助。这一部分内容包括数据库镜像会话中不同的数据库状态、同步和异步的日志记录传输机制、以及故障转移次序。

　　配置和安全性

　　一旦确定了主服务器、镜像服务器、以及可选的见证服务器，设置数据库镜像主要包括三个步骤。

　　1.必须备份数据库并使用norecovery在镜像数据库上还原该数据库。

　　注意：在备份数据库并还原到镜像数据库之前，主数据库必须设置为FULL还原模型。如果必须在事务日志中传输Bulk-logged记录，那么数据库镜像将无能为力。镜像服务器必须有足够的磁盘空间以允许和主数据库同样的文件增长。如果希望在镜像服务器中创建数据库快照，那么还必须为快照提供额外的磁盘空间。

　　如果备份、拷贝、以及还原数据库耗费了相当长的时间，那么可能需要现在原始数据库上进行一次事务日志备份来控制日志的大小。但是，如果通过日志到日志的备份清理了日志记录，数据库镜像将无法初始化。因此必须在初始化数据库镜像之前在镜像数据库上按顺序恢复那些事务日志记录备份。

　　2.参与数据库镜像会话的服务器必须彼此信任。对于本地通信而言，例如一个域内的通信，信任意味着SQL Server实例登陆账号必须有权限连接到其他镜像服务器，也包括endpoints。首先在每个服务器上使用CREATE LOGIN命令，然后使用GRANT CONNECT ON ENDPOINT命令（参阅" in SQL Server Books Online中“Example of Setting Up Database Mirroring Using Windows Authentication”）

　　非信任域之间的通信必须使用证书。如果使用CREATE CERTIFICATE语句创建自签名的证书，基本上所有数据镜像证书的要求都可以满足。确认在CREATE CERTIFICATE语句中将证书标记为ACTIVE FOR BEGIN_DIALOG。

　　3.下一步是创建数据库镜像的endpoints。创建endpoints要求您必须具有SQL Server instance的系统管理员权限。必须在每台服务器上创建专门用于数据库镜像的endpoints. 创建endpoints最简单的方式就是使用Configure Database Mirroring Security向导，可以在Database Properties对话框中Mirroring页面上单击Configure Security按钮启动该向导。Configure Security对话框会在构造和执行CREATE ENDPOINT命令之前，提示您输入正确的计算机名称和端口号，以及可选的登陆帐号。（参阅SQL Server Books Online中 “How to: Create a Mirroring Endpoint (Transact-SQL)”）　

　　如果在域中设置数据库镜像，并且所有的SQL Server实例使用相同的服务帐号和密码，那么就不需要在每个服务器上创建登陆帐号。类似的，如果在工作组中，并且所有的SQL Server实例使用相同的服务帐号和密码，也不需要在每个服务器上创建登陆帐号。设置endpoints时将Configure Database Mirroring Security向导中的登陆帐号保留为空就可以了。

　　每个数据库endpoint必须指定服务器上一个唯一的端口号。如果使用不同服务器上的SQL Server实例，那么这些端口号可以是相同的。Configure Database Mirroring Security向导会自动建议您使用5022作为端口号。如果任何SQL Server实例运行在同一台服务器上，那么每个实例的端口号必须唯一，所有的镜像端口号也必须唯一。

　　假设在高可用镜像会话中有三台服务器。Server A是主服务器，server B是镜像服务器，server W作为见证服务器。对于server A而言，下面的命令在5022端口创建endpoint：

　　注意：角色被指定为PARTNER，这样该服务器可以担当数据库镜像的主服务器或者镜像服务器。在server B上执行相同的命令。因为server B是独立物理服务器上的SQL Server实例，因此可以使用相同的端口号。然后对于server W，使用

　　注意：对于server W，角色被指定为WITNESS。

　　默认不启动endpoint。接下来在每个服务器上使用下面的命令来启动endpoint：

　　可以在CREATE ENDPOINT命令中插入可选的STATE选项。在每台服务器上反复执行该选项。

　　使用CREATE ENDPOINT创建endpoint时，可以通过协议特定的参数根据IP地址来限制对endpoint的访问。结合RESTRICT_IP with ALL选项和EXCEPT_IP加上那些允许访问的特殊IP地址可以对一组IP地址作限制。（参阅SQL Server Books Online中的See “CREATE ENDPOINT”）。

　　查询每个服务器的sys.database_mirroring_endpoints目录视图来检查数据库镜像的endpoints：

　　4. 要启动数据库镜像，接下来指定指定伙伴服务器和见证服务器。 必须具有数据库管理员权限才可以启动和管理一个给定的数据库镜像会话。在server A，即打算作主服务器的机器上设置主数据库角色以及伙伴（镜像）服务器：

　　镜像伙伴的名称必须为完全限定计算机名。决定机器的完全限定名称可能有些难，不过Configure Database Mirroring Security向导会在建立endpoint时自动找出它们。

　　从命令行提示中运行下面的命令也可以找出一台机器的完全限定名称：

　　IPCONFIG /ALL

　　将"Host Name"和"Primary DNS Suffix"连接到一起。如果您看到的信息类似于：

　　Host Name . . . . . . . . . . . . : A

　　Primary Dns Suffix　. . . . . . . : corp.mycompany.com

　　那么计算机名就是A.corp.mycompany.com。加上'TCP://'前缀然后再附加':<端口号>' ，就是镜像伙伴名称。

　　在镜像服务器上重复相同的命令，但是要指定主服务器名称：

　　接下来在主服务器上指定见证服务器：

　　执行完CREATE ENDPOINT后见证服务器上就不需要执行其他命令了。

　　最后，在主服务器上指定会话的safety级别：

　　此时，镜像将自动启动，然后主服务器和镜像服务器将进行同步。

　　可以调整判定镜像伙伴是否故障的超时值，使用ALTER DATABASE命令的TIMEOUT参数。例如将TIMEOUT值改为20秒（默认是10），在主服务器上执行：

　　最后，在主服务器上使用ALTER DATABASE和REDO_QUEUE选项可以镜像服务器上redo队列的大小。下面的查询将镜像服务器的redo队列设置为100兆：

　　只要指定了镜像伙伴，镜像将立即启动。

　　数据库镜像目录视图

　　数据库镜像会话包括组成伙伴的服务器，可能还有见证服务器之间的关联。每台参与镜像的服务器都保存关于镜像会话和当前数据库状态的元数据。可以在主服务器和镜像服务器上通过查询sys.database_mirroring目录视图来检查会话状态。使用另一个视图sys.database_mirroring_witnesses可是返回见证服务器的信息（要想获得两个目录视图中所有列的更完整的描述，请参阅　SQL Server Books Online的“sys.database_mirroring" and "sys.database_mirrroing_witnesses”）。

　　了解数据库镜像会话如何工作以及数据库处于何种状态的一种不错的方法就是检查目录视图里的数据。我们从高可用配置开始（safety设置为FULL，有一台见证服务器）。下面的查询返回了主服务器或者见证服务器上数据库镜像会话的基本描述信息。

　　在见证服务器上运行下面类似的查询，可以返回见证服务器的相关描述信息。

　　现在来比较在一个典型的数据库镜像会话中两个查询的输出结果。假设已经设置了server A到 server B的数据库镜像，使用safety为FULL。（设置以下配置的示例代码，请参阅后面的实现数据库镜像“配置和安全性”）见证服务器是server W，对AdventureWorks数据库做镜像。表3显示了两个查询的输出结果：

　　表3：高可用镜像会话，两个伙伴服务器sys.database_mirroring输出结果

　　注意数据库镜像会话中的每个伙伴保存的所有元数据从另一个伙伴的角度来看是完全相同的。每个伙伴保存其数据库名称、整个会话的safety设置、数据库的镜像状态、以及两个序列计数器。

　　◆mirroring_safety_sequence计数器保存在两个伙伴上，只要safety设置改变时将增加该计数器的值。

　　◆mirroring_role_sequence计数器保存在两个伙伴以及见证服务器上，只要发生故障转移就增加该计数器的值。

　　伙伴数据库的状态以及见证服务器的状态都保存在每个伙伴服务器上：

　　◆mirroring_state_desc显示了会话中伙伴数据库的状态。

　　◆mirroring_witness_state_desc显示了会话中见证服务器的状态。

　　最后，每个伙伴都包含一个mirroring_failover_lsn。LSN是一个日志序列号，用于唯一标识每条事务日志记录。 镜像伙伴将上次硬化的最后一组日志记录的最高LSN +1保存起来。在上表中，由于主数据库中只有为数不多的活动，因此 镜像转移故障的lsn和主服务器以及见证服务器的lsn相同。当传输大量数据时，可能就会发现主服务器的lsn值大于镜像服务器的值，因为镜像服务器的运行有些滞后。

　　现在比较一下在见证服务器上找到的元数据。下表显示了来自见证服务器元数据的一些可比较信息：

　　表4：见证服务器上sys.database_mirroring_witnesses的输出，关联了伙伴的元数据

　　注意见证服务器的元数据包含了safety的描述、safety的序列号、以及角色序列号。见证服务器还保存了会话是否被挂起的信息，以及主服务器和镜像服务器的名称。注意见证服务器的目录视图并没有报告镜像故障转移的lsn，而且也不保存数据库状态。

　　数据库镜像所需的全部元数据（特别是故障转移lsn和伙伴服务器名称）都保存在镜像伙伴上。见证服务器只保存在高可用模式下作为见证者必须保存的那些数据，特别是用于跟踪会话中角色转换数目的角色序列号。该计数器用于帮助判定何时一台主服务器可以做角色转换。相关知识会在下一部分介绍的场景中进行阐述。

　　数据库镜像状态和状态转换

　　在数据库镜像会话过程中，每台伙伴服务器都对数据库状态作记录和保存，可以通过sys.database_mirroring目录视图来查看。mirroring_state列返回状态号，mirroring_state_desc列返回状态的描述性名称。（要想获取关于数据库状态号和描述性名称的完整列表，请看SQL Server Books Online中的“sys.database_mirroring”）。同样的目录视图还用于报告见证服务器的状态信息。

　　除了为每个数据库报告状态信息以外，还有三个重要术语用来对数据库镜像中的服务器和数据库进行描述。

　　1.主服务器上的数据是exposed ，当它进行事务处理但是没有日志数据被发送到镜像服务器。

　　2.不能提供数据库服务 – 当主服务器不允许任何用户连接到数据库，不允许任何事务处理。

　　3.服务器被孤立 – 当它无法联系数据库镜像会话中任何其他服务器，同时别人也联系不上它。

　　当主数据库是exposed，它可以接收用户连接和进行事务处理，但是没有日志记录被发送到镜像数据库。因此如果主数据库失败了，那么镜像数据库不包含任何自主数据库进入exposed状态后主服务器上发生的事务。同样的，也不可以清理主数据库的事务日志，这导致日志文件的无限增长。

　　当safety设置为FULL时，如果主服务器无法和其他服务器组成quorum，它将停止提供数据库服务。主服务器将不允许主数据库上的用户连接和事务，并断开所有当前的用户。只要主服务器能再次组成quorum，就立刻重新提供数据库服务。

　　一台服务器可能运转正常但是它和数据库镜下会话中的其他服务器之间的通信连路中断了。如果那样的话，我们称服务器被孤立了。 当safety为FULL时，如果主服务器被孤立，那么它将无法提供数据库服务，因为会话中没有其他服务器可与之共同组成quorum。