因为Server A无法看见见证服务器Server W或者原先的镜像伙伴Server B，因此必须进入disconnected状态并使数据库不可用。

　　Server B和Server W可以组成quorum。Server B无法看见Server A，因此Server B试图成为主服务器并使其数据库联机。因为Server W也看不到Server A，因此同意了Server B。 Server B现在有了quorum，担当起会话的主服务器角色，然后还原其数据库。

　　如果恢复通信连路，Server A能够看到Server B如今成为主服务器，并检测到见证服务器Server W也认可Server B为主服务器。Server A将其角色转换为镜像服务器，然后尝试与新主服务器同步。同步之后的配置结果如图15所示。

　　图15：该场景通信连路恢复后的版本，数据库镜像按反方向进行

　　总结：见证服务器位于镜像服务器的远程站点上，如果站点间的通信链路中断，自动的故障转移产生。

　　场景 HACL5：两个站点，见证服务器位于主服务器站点

　　在这个高可用场景中，假设将见证服务器放置在主服务器所在的同一站点上，如图16所示，然后两个站点间的通信中断了。

　　图16：主服务器/见证服务器和镜像服务器之间的通信中断

　　在这种情况下，负责镜像数据库的Server B被主服务器和见证服务器孤立。

　　Server A和Server W继续组成quorum，因此Server A保持其数据库为主数据库。

　　但是，Server A同时将数据库设置成disconnected状态，因为它无法看到Server B也不可能进行数据传输。Server B也无法看到Server A，因此也进入disconnected状态。配置结果如图17所示。

　　图17：该场景中通信失败导致两个伙伴为disconnected状态

　　Server A继续接受事务但无法截断事务日志记录。如果迅速恢复了链路，镜像会话还可以重新同步并返回到初始操作状态。

　　总结：见证服务器和主服务器位于同一站点，镜像服务器位于远程站点，站点之间的通信中断不会产生自动的故障转移。

　　总结：高可用场景中通信连路中断

　　在使用三台独立服务器的高可用配置中，有三条独立的通信连路。

　　◆主服务器/镜像服务器出现通信失败，没有自动的故障转移会发生。

　　◆主服务器/见证服务器首先出现通信失败，随后主服务器/镜像服务器通信中断 ，自动的故障转移将发生。恢复链路将继续反方向的数据库镜像。

　　◆镜像服务器/见证服务器通信失败，没有自动的故障转移会发生。

　　在只有一条通信连路的高可用配置模式中，见证服务器驻留在主服务器或者镜像服务器所在站点上。

　　◆见证服务器驻留在镜像服务器的远程站点上，如果站点之间的通信链路中断，那么自动的故障转移将发生。

　　◆见证服务器和主服务器位于同一站点上，镜像服务器在远程站点，站点之间的通信中断不会导致自动的故障转移发生。

　　高保护方案

　　高保护模式配合safety FULL一起工作，但没有见证服务器。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。这使场景数量大大降低。

　　场景1：高保护操作模式只包括两个SERVER实例，主服务器和镜像服务器。由于没有见证服务器，自动的故障转移师不可能的。服务器之间仅有一条通信连路会中断，导致配置结果如图18所示。

　　图19：高保护场景中如果镜像服务器不可用 ，那么主数据库不受影响

　　场景3：高保护场景中如果主数据库不可用，那么镜像数据库必须继续担任镜像，但进入disconnected状态，如图20所示。

　　图20：高保护场景中如果主数据库不可用，那么镜像数据库进入disconnected状态

　　因为高保护操作模式使用safety FULL，因此任何破坏都导致主数据库比可用，而镜像数据库继续维持recovering状态：没有数据库是联机的。其结果是：该模式对于高可用性需求而言不是一个好的解决方案，因此更适合作为一种临时方案，如必须将见证服务器移除一小段时间。

　　高性能方案

　　高性能操作模式配合safety OFF一起工作。 没有见证服务器角色。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。尽管类似于高保护模式，但由于safety设置为OFF，因此其行为与高保护模式并不相同。

　　场景1：在高性能操作模式中使用两个SQL SERVER实例。一个负责主数据库另一个负责镜像数据库。因此服务器之间只有一条通信连路并且可能中断，导致如图21所示的配置结果。

　　图21：高性能场景中通信失败，两个伙伴均进入disconnected状态，但是主数据库依然可用

　　由于safety设置为OFF， Server A不需要quorum就可以使数据库保持为可用状态。因此尽管已经进入disconnected状态，主服务器还可以继续接受用户活动。如果通信恢复，那么镜像数据库将尝试追赶主数据库但无法做到，或者出现redo错误，如果它不能找回所有丢失的事务。

　　场景2：在高性能场景中，如果镜像数据库不可用，那么主数据库结果显示在图22中。

　　图22：如果在高性能模式下镜像服务器不可用，主数据库不受影响

　　由于safety设置为OFF，因此主数据库依然可用。

　　场景 3：如果在高保护模式下主数据库不可用，那么镜像数据库依然作为镜像，但将被断开，如图23所示。

　　图23：如果主服务器不可用，那么Server B不会受到影响，但是进入disconnected状态

　　高性能操作模式和高保护模式一样，没有自动的故障转移。由于safety设置为OFF，当镜像服务器不可用时，主服务器将保持其数据库为可用。同样由于safety设置为OFF，不保证事务一定到达镜像数据库。如果强制故障转移到镜像服务器，那么有些事务可能会因此丢失。

　　实现数据库镜像

　　可以在SQL SERVER 2005 Books Online，数据库镜像主题的“How To”中找到实现数据库镜像的基本信息。在白皮书的这一部分，我们来研究实现数据库镜像的一个特殊示例以及最佳实践。

　　监视数据库镜像

　　通过在SQL SERVER 2005 Management Studio的Object Explorer中检查主数据库和镜像数据库，可以查明每个数据库镜像伙伴的状态。如果主数据库和镜像数据库是同步的，那么Object Explorer就在主数据库名称的后面附加一个（Principal， Synchronized）消息，在镜像服务器名称的旁边附加一个（Mirror， Synchronized）。可以在主服务器上弹出的数据库 Properties对话框中观察Mirroring页面下方的状态框，从而检查数据库镜像会话的状态。（数据库 Properties对话框不会在镜像服务器上打开）。

　　还可以查询数据库镜像目录视图sys.database_mirroring和sys.database_mirroring_witnesses（更多关于使用目录视图检查镜像会话中数据库状态的信息，请参阅该白皮书前面数据库动态部分的“Database Mirroring Catalog View Metadata”。SQL SERVER Books Online中也包含了目录视图的完整文档。）

　　数据库镜像性能计数器

　　可以使用性能计数器监视数据库镜像会话中镜像伙伴之间的网络流量。 SQL Server Database Mirroring对象包含了大量有用的性能计数器来监视主服务器和见证服务器。（参阅SQL Server Books Online中的"Monitoring Database Mirroring"）

　　可以在每个数据库上设置Database Mirroring对象。如果需要在一台服务器上监视不止一个数据库，那么既可以单独监视某个数据库的活动，也可以监视所有数据库的全部活动。

　　对于主服务器，Log Bytes Sent/sec 计数器指示主服务器发送日志数据到镜像服务器的速率，而Log Send Queue指示在某个给定时间点事务日志缓冲区中有多少字节要发送到镜像服务器。随着事务日志记录从主服务器发送到镜像服务器，主服务器的发送队列将逐渐缩小，但也会随着新的日志记录进入日志缓冲区而增长。主服务器上的Transaction Delay 计数器指示主服务器由于等待镜像服务器关于日志接收的确认消息导致的延迟。主服务器上的Sent/sec计数器与主服务器给镜像服务器发送的数据页面有关。

　　在镜像服务器上，Log Bytes Received/sec指示镜像服务器和主服务器之间相差多少。（见上面Log Bytes Sent/sec 计数器）。Redo Queue 计数器指示redo队列的大小。镜像服务器在redo阶段使用redo队列重新执行来自主服务器的事务。Redo Bytes/sec指示镜像服务器执行redo队列中事务的速率。

　　对于每个伙伴服务器，Sends/sec和Receives/sec 计数器指示有多少个发送和接收动作Bytes Sent/sec和Bytes Received/sec 计数器指示在每个伙伴服务器上那些发送和接收动作包含的字节数。

　　估计Redo和Catch-up时间

　　如果出现故障转移，可以使用Redo Queue和Redo Bytes/sec来估算镜像数据库完成redo并成为可用状态需要花费的时间。使用下面的简单公式进行计算：

　　估计的redo时间（秒） =

　　(Redo Queue)/(Redo Bytes/sec)

　　类似的，如果主服务器上的活动领先于镜像服务器，可以使用Log Send Queue和Log Bytes Received/sec 计数器估算镜像服务器追赶上主服务器需要花费的时间。 下面给出了计算公式：

　　估计的catch up时间（秒） =

　　(Log Send Queue)/( Log Bytes Received /sec)

　　Profiler事件

　　SQL Server 2005 Profiler包含了一个数据库镜像事件类。Database:Database Mirroring State Change事件将记录被监视服务器是否发生了状态改变。（参见SQL Server Books Online主题“Database Mirroring State Change Event Class”）。当使用这个事件类时包含Database Name和State来会对您大有帮助。可以使用该事件通知您数据库镜像会话中的任何状态改变。

　　数据库镜像排错

　　数据库镜像最容易出错的地方就是配置过程和运行过程。

　　排除设置错误

　　如果已经设置了数据库镜像但是无法启动，那么重新开始所有配置步骤。

　　1.确认镜像服务器尽可能接近主数据库。如果尝试启动数据库镜像时收到了以下的错误消息：

　　远程“AdventureWorks”数据库没有前滚到本地数据库日志副本中包含的一个时间点。（Microsoft SQL SERVER， 错误：1412）

　　说明镜像数据库滞后于主数据库。需要将主数据库的事务日志备份应用到镜像数据库（使用NORECOVERY），从而使镜像数据库恢复到某个时间点，并可以从此时间点开始接收来自主数据库的日志记录。

　　2.确认每个服务器的SQL SERVER Windows服务帐户彼此相互信任。如果服务器所在的域没有建立信任关系，那么确保证书是正确的。

　　3.通过查询sys.database_mirroring_endpoints目录视图，确认不仅定义而且启动了endpoint：

　　确认使用了正确的完全限定计算机名称以及正确的端口号。如果在一台物理服务器的多个实例之间配置镜像，那么端口号就必须是唯一的。SQL SERVER服务登陆帐号需要CONNECT到endpoint的访问权限。

　　最后，确认为服务器定义了正确的endpoint角色。

　　4.确认在ALTER DATABASE命令中指定了正确的镜像伙伴名称。可以在主服务器和镜像服务器的sys.database_mirroring目录视图中（以及高可用模式下的sys.database_mirroring_witnesses witnesses）检查镜像伙伴名称。

　　排除运行时错误

　　如果数据库镜像设置正确，然后在运行过程中出现了错误，请检查会话的当前状态。如果由于错误而使镜像处于SUSPENDED状态，就可能在镜像服务器上产生redo错误。检查并确认镜像服务器上有足够的磁盘空间用于redo（数据文件所在分区的剩余空间）和日志hardening（日志文件所在分区的剩余空间）。当您准备重新启动会话时，使用ALTER DATABASE来重新开始会话。

　　如果无法连接到主数据库，最可能的原因就是safety设置为FULL并且主服务器无法组成quorum。这种情况能够发生，例如，如果系统在高保护模式下运行（safety为FULL但没有见证服务器），镜像服务器又断开了和旧的主服务器的联系。可以在镜像服务器上使用下面的命令强制镜像服务器进行恢复：

　　问题就在于一旦恢复了镜像数据库，镜像服务器将成为主服务器但却无法形成quorum，因此无法服务于数据库。如果那样的话，只要把safety设置为OFF就可以允许它服务于数据库了。

　　安全性与性能

　　数据库镜像的性能是关于活动类型和事务安全性的一个函数。

　　传输日志到镜像服务器会影响主服务器性能。数据库镜像给主服务器带来的开销是关于活动类型的一个函数。数据库镜像在多用户以及大量长事务的系统上操作性能最好，因为数据库服务器正常的事务活动会掩盖传输日志记录到镜像服务器的引起的开销。如果单个用户顺序执行大量短事务，那么数据库镜像给每个事务造成的开销将十分显著。

　　主服务器性能同样受Safety设置的影响。当safety设置为FULL时，主服务器必须等待镜像服务器表示已经收到日志记录的确认信息，才可以将事务提交消息返回给客户端。如果有大量的用户和大量的长事务，那么这种等待导致的开销并不明显。单线程系统和包含许多小事务的系统在safety OFF时可以运行的更好。

　　因为镜像服务器连续不断地重新执行从主服务器接收的数据更新事务，镜像服务器的数据缓存将变得'hot'。 换句话说，就是使用那些和主服务器类型相同的数据更新操作所涉及的数据页面和索引页面来加工缓存。为了使镜像服务器的缓存更接近于主服务器缓存，数据库镜像将一个SELECT提示也传递给镜像服务器，从而可以在镜像服务器重新生成用于数据查询的缓存内容。这样可以帮助镜像服务器更接近于主服务器，同时减少故障转移时剩余的redo时间。很明显，镜像服务器上任何其他活动，包括对数据库快照的查询也会影响缓存的状态，并因此增加故障转移时完成日志redo的时间。

　　测试数据库镜像

　　当设置自己的系统来测试数据库镜像时，有许多选项可用。所有数据库镜像都要求在数据库镜像会话中的服务器必须是不同的SQL SERVER实例。因此可以在一台物理服务器上配置和测试数据库镜像，如果您安装了多个SQL SERVER 2005关系数据库引擎。也可以在一台虚拟服务器上测试多个实例，但是在物理服务器上进行测试更加可信。

　　进行数据库镜像的负载和压力测试时需要不同的物理服务器。一台服务器上的两个或者三个实例可能会消耗不切实际的服务器资源。此外服务器之间的网络连接质量也同样重要。主服务器和镜像服务器之间的网络越好，日志记录和消息传送的速度就越快。

　　最逼真的测试就是在一台真正的目标服务器或者试验台上进行，并且和最终系统的物理属性完全相同。当您在一台服务器上测试多个实例时，只能通过停止实例或者关机的方式来模拟数据库镜像中服务器失败的效果。使用多台物理服务器时，就可以通过断开网线的方式来测试网络连接失败的效果。

　　下面的实践能够帮助您创建测试环境：

　　◆要测试服务器失败，关闭SQL SERVER实例，通过SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。

　　◆要测试通信失败，拔掉服务器上的网线。

　　◆要测试数据库失败，停止SQL SERVER服务，重新命名。mdf文件，然后再重启SQL SERVER。

　　◆要导致镜像数据库的redo错误， 为主数据库添加一个新文件，将文件存放在主服务器存在但镜像服务器中不存在的分区中。

　　◆另一种导致镜像服务器redo错误的方法就是强制镜像服务器的数据库文件空间不足。

　　◆要迫使主服务器的数据库停工，强制主数据库数据文件空间不足。

　　◆要导致主数据库或镜像数据库日志缓冲区hardening失败，强制日志文件空间不足。

　　为故障转移准备镜像服务器

　　数据库镜像其实就是数据库到数据库的联系。只有数据库中的数据会通过日志记录从主数据库发送到镜像数据库。就像日志传送和复制一样，必须准备备用服务器和镜像数据库，以便出现故障时可以完全接管主数据库的工作。当您准备镜像服务器时，应该从以下几个层面进行考虑。

　　在物理服务器层面，确保备用服务器和主服务器拥有相同的或者尽可能接近的物理CPU和内存配置，否则备用服务器在故障转移后将无法胜任工作。此外可能还有一些支持应用程序、监视器、以及支持程序运行的可执行文件等等，都需要在镜像服务器上进行配置。

　　在SQL SERVER层面，确保备用服务器和主服务器拥有相同的SQL SERVER配置（例如，AWE、最大并行化程度）。但最重要的就是登陆帐户和账户权限。主服务器上所有激活的SQL SERVER登陆帐户都必须同时存在镜像服务器上，否则一旦出现故障转移，那么应用程序将无法使用这些登陆帐户连接到新的主服务器上。可以使用SQL SERVER集成服务的Transfer Logins任务将登陆帐户和密码从一台服务器拷贝到另一台服务器，但您还必须为这些登陆帐户设置数据库权限。如果将登陆帐户传输到另一个不同的域，那么可能出现不匹配色的SID，需要您去匹配它们。

　　SQL SERVER主服务器上可能还存在大量的支持对象需要被转移到备用服务器上：SQL Agent作业和警报、SQL SERVER集成服务包、支持数据库、连接服务器的定义、备份设备、维护计划、SQL Mail或者数据库设置、可能还有分布式事务协调器（MSDTC）设置，等等。

　　当SQL Agent作业被传输到备用服务器后，大部分将被迫设置为禁用。一旦出现故障转移，需要您启用这些作业。

　　故障转移后，如果应用程序使用SQL SERVER验证，还需要将SQL SERVER新的主服务器上的登陆帐户解析成新的主服务器上的数据库用户。完成该任务最好的工具就是存储过程sp_change_users_login。

　　多数据库的问题

　　许多应用程序使用一台服务器上的多个数据库。多个数据库可以被一个应用程序引用，也可能被多个应用程序引用。但是数据库镜像每次只能在一个数据库上工作。当您设计数据库镜像时需要考虑这一点。

　　如果您希望高可用模式，那么最适合的就是一个应用程序配合一个数据库。当自动的故障转移发生时应用程序不再需要主服务器上的任何数据库。考虑如果多个数据库在一台服务器上并且操作在高可用模式下，那么可能出现什么情况呢？如果一台物理服务器掉电了，或者一个SQL SERVER实例失败了，或者网络通信失败了，那么所有数据库将自动故障转移到备用服务器，而他们的镜像将成为新的主数据库。如果见证服务器可用，应用程序可以连接到新的主数据库。但是如果某个数据库由于磁盘失败而产生了分页，因此只有这个数据库被故障转移，那么会发生什么呢？如果那样的话，应用程序就有可能无法连接到所有正确的数据库。

　　因此依赖多数据库的应用程序不适合使用数据库镜像的高可用模式。您可以将safety设置成OFF，实际上就是不使用自动故障转移，但您必需使用某种高效的方式保持和其它数据库服务器的同步。

　　数据库镜像和高可用性技术

　　SQL SERVER 2005现在至少支持四种高可用性技术，尽管不同技术相互之间有些功能重叠，但每种技术都有各自的优缺点。这些技术是：

　　◆数据库镜像 – 为了便于讨论，我们将考虑高可用操作模式以及FULL safety和见证服务器。

　　◆故障转移群集 – 最典型的配置就是2节点的Windows故障转移群集配置一个SQL SERVER实例。

　　◆日志传送 – 采用SQL SERVER内置的日志传送和一个独立的监视服务器。

　　◆事务复制 – 一台分发服务器和一台订阅服务器，如果发行服务器失败，订阅服务器作为备用服务器。

　　在这一部分我们将比较这四种技术的基本功能，然后深入探讨怎样对数据库镜像进行补充或者提供一个更好的解决方案。

　　下表显示了四种技术的几个高可用性功能。

　　表14：比较SQL SERVER 2005高可用性技术

　　上表总结了所有四种高可用技术的特性。下一部分将进行更详细的比较。

　　数据库镜像和群集

　　数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余。数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 SQL SERVER实例，两个实例有不同的名称；而群集中的 SQL SERVER实例则使用相同的虚拟服务器名称和IP地址，而且无论哪个节点主持群集实例，虚拟服务器名称和IP地址始终保持不变。

　　如果您需要在服务器一级的数据库保护（例如，您的应用程序需要同时访问统一服务器上的多个数据库），故障转移群集将是更适合的选择。但是，如果每次只须为一个数据库提供可用性，那么数据库镜像具有更多优势。

　　数据库镜像不像群集那样需要专门的硬件，也没有共享存储介质失败的潜在危险。数据库镜像可以在最短时间内让备用数据库开始提供服务，其速度快于任何其它的高可用技术。此外，数据库镜像能够与ADO。NET和SQL Native Access Client很好的配合在一起，从而实现客户端的故障转移。

　　不能在群集中使用数据库镜像，但是可以考虑使用数据库镜像作为一种手段来创建群集数据库实例的一个热备用份。这样做需要特别小心，因为群集的故障转移时间长于数据库镜像的超时值，高可用模式下的镜像会话将对群集的故障转移做出反应，认为这是主服务器失败了，然后会将群集节点设置为镜像状态。

　　数据库镜像和事务复制

　　数据库镜像和事务复制都建立在读取原始服务器事务日志的基础上，但此后采用的技术就截然不同了。（更多关于事务复制的细节，请参阅SQL SERVER Books Online中的相关主题）。事务复制多用于配置高可用性，因为它可以将发行数据库中的用户事务在几秒钟内递送到订阅数据库中。数据库镜像的优点是速度对于甚至快于复制，但需要递送所有的数据库事务，而不单单是与用户表相关的事务。

　　事务复制技术适合于将数据扩充到多个订阅者。事务复制的订阅数据库通常是只读的，如果需要近乎实时的数据访问，那么事务复制是理想的候选者。

　　数据库镜像与事务复制兼容，如果需要维持发行数据库的一个热备份，数据库镜像就是非常有用的一种方式。其它用于保护复制发行商的方式，例如日志传送无法在发行商自己的订阅者之前维持发行商的备用服务器。换句话说，事务复制将事务日志递送给订阅者的速度要快于事务日志备份。正是因为数据库镜像速度很快，因此特别适合用于维持发行数据库的热备份。

　　但是如果发行服务器失败，就必须手动使用还原好的备用数据库重新建立发行商，然后重新连接到分发服务器，， 使用日志传输维护发行商服务器的备用服务器所必须做的工作与此相同。

　　数据库镜像和日志传输

　　数据库镜像和日志传输都依赖SQL SERVER数据库提供的恢复和还原功能。在数据库镜像中，镜像数据库始终保持recovering状态，连续不断地还原来自主数据库的事务日志。而日志传输中的备用数据库则周期性地应用事务日志备份中的事务。因为bulk-logged数据被附加到事务日志备份中，因此日志传送可以工作在bulk-logged恢复模型下。数据库镜像则不同，它直接将日志记录从主数据库传送到镜像数据库中而且不能递送bulk-logged数据。

　　很多情况下数据库镜像可以提供与日志传送相同的数据冗余以及更高的可用性和自动故障转移。但是，如果应用程序依赖一台服务器上的多个数据库，那么日志传送是有效的方式（参阅前一部分介绍的“Multi-Database Considerations”）。

　　此外，某些数据库镜像场景中还可以通过日志传送作为补充。例如：您可以某处配置一个高可用数据库镜像，然后将主数据库日志传送到远程站点以提供灾难恢复。图24显示了如何进行这种配置。

　　图24：将主数据库日志传送到远程服务器

　　这种方式的优点就是：一旦整个站点失败了，第二个站点上的数据还继续可用。但是，如果数据库镜像失败了，从Server B到远程备用服务器的日志传送通常必须重新开始。

　　其它使用日志传送补充数据库镜像的场景就是作为主服务器的本地备用，主服务器的数据库镜像会话用于灾难恢复。此时，数据库镜像会话运行在高性能操作模式下，远程站点的镜像服务器作为远程备用服务器。

　　图25：通过主数据库日志传送的方式来保留所有的事务

　　在高性能模式中存在的数据丢失，如果主服务器失败并且使用强制恢复服务的方式恢复了镜像服务器。如果您正在对旧的主服务器进行日志传送，并且如果旧的主服务器事务日志文件没有损坏，那么可以对主数据库进行“结尾日志”备份来获得事务日志中最后一组记录。如果备用日志传输数据库已经应用了所有其它的事务日志备份，您就可以将结尾日志备份应用到备用服务器，这样不会丢失旧的主服务器上的任何数据。然后可以对日志传送备用服务器中的数据和远程数据库做个比较，在需要时将丢失的数据拷贝到远程服务器。

　　当您对比日志传输和数据库镜像功能时，需要明确的一点就是：对主数据库进行数据库和日志备份很重要。将这些日志备份应用到的日志传送服务器可以对数据库镜像配置起到补充作用。

　　结论

　　数据库镜像是SQL SERVER 2005中的新技术，可以实现高可用性和高性能的可数据库冗余解决方案。在数据库镜像中，当主数据库的事务日志缓冲区被写入磁盘时（硬化的），事务日志记录就从主数据库直接发送到镜像数据库。这种技术可以使镜像数据库几乎和主数据库的数据保持同步，同时不会丢失提交的数据。在导可用性操作模式中，如果主服务器失败了，那么镜像服务器将自动成为新的主服务器并还原数据库。使用新的ADO．NET或者SQL Native Access Client驱动程序，应用程序还可以从自己的服务器上进行自动的故障转移。数据库镜像成为SQL SERVER 2005提供的高可用技术家族中的新成员。