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