-- Specify the partner from the principal server
现在来比较在一个典型的数据库镜像会话中两个查询的输出结果。假设已经设置了server A到 server B的数据库镜像，使用safety为FULL。（设置以下配置的示例代码，请参阅后面的实现数据库镜像“配置和安全性”）见证服务器是server W，对AdventureWorks数据库做镜像。表3显示了两个查询的输出结果：
表3：高可用镜像会话，两个伙伴服务器sys.database_mirroring输出结果
|
镜像伙伴的
元数据列 |
主服务器值：
Server A |
镜像服务器值：
Server B |
|
db_name(database_id) |
AdventureWorks |
AdventureWorks |
|
mirroring_role_desc |
PRINCIPAL |
MIRROR |
|
mirroring_safety_level_desc |
FULL |
FULL |
|
mirroring_state_desc |
SYNCHRONIZED |
SYNCHRONIZED |
|
mirroring_safety_sequence |
1 |
1 |
|
mirroring_role_sequence |
1 |
1 |
|
mirroring_partner_instance |
TCP://B.corp.mycompany.com:5022 |
TCP://A. .corp.mycompany.com:5022 |
|
mirroring_witness_name |
TCP://W.corp.mycompany.com:5022 |
TCP://W.corp.mycompany.com:5022 |
|
mirroring_witness_state_desc |
CONNECTED |
CONNECTED |
|
mirroring_failover_lsn |
95000000007300001 |
95000000007300001 |
主服务器数据库状态
当safety设置为FULL，主数据库的正常操作状态时SYNCHRONIZED状态。当safety设置为OFF，主数据库的正常操作状态是SYNCHRONZING状态。
◆假如safety设置为FULL，主数据库的起始状态始终是SYNCHRONIZING，当主数据库和镜像数据库事务日志同步后，数据库状态就转换成SYNCHRONIZED， 由于见证服务器状态真正记录在伙伴服务器而不是见证服务器上，因此这些状态是从有利于伙伴的角度来设置的，因此当您看到见证服务器为DISCONNECTED状态时，意味着伙伴和见证服务器断开了。数据库镜像启动后，假如镜像服务器无法与主服务器进行初始化，那么见证服务器进入UNKNOWN状态。
传输事务日志记录
SQL Server主服务器和镜像服务器传输消息和日志记录的次序根据事务安全性的设置而不同。我们先研究同步传输，然后再研究异步传输。
当SQL Server将事务事件记录在事务日志中时，日志记录被写入磁盘前暂时存放在日志缓冲区中。 数据库镜像时，每次日志缓冲区被输出到硬盘时（硬化），主服务器也将相同的日志记录块发送到镜像服务器。
1. 当safety设置为FULL，只要SQL Server主服务器硬化它的日志记录块，就同时将相同的日志记录块发送到镜像服务器，并认为本地的日志I/O和远程镜像服务器的日志I/O从本质上来说是一样 的。这种传输称为同步的，因为在一个事务提交之前，主服务器既要等待本地的I/O（硬化）还要等待等待镜像服务器有关完成I/O（硬化）的答复。
每次主服务器或者镜像服务器硬化日志缓冲区时，都会将缓冲区中最高的日志序列号（LSN）+ 1作为mirroring_failover_lsn记录在元数据中。
mirroring_failover_lsn用于协商事务日志最后的保障点，这样两个伙伴数据库就可以在初始化时保持同步，在故障转移后也保持同步。
当主服务器发送日志记录给镜像服务器时，主服务器上的mirroring_failover_lsn通常会提前一些。镜像服务器硬化日志记录时会记录其mirroring_failover_lsn，然后回复主服务器。但是等主服务器接收到来自镜像的确认信息时，主服务器可能已经开始硬化新的一组日志记录了。
表8显示了主服务器和镜像服务器safety为FULL时的一个事件序列示例。
表8：Safety为FULL （同步传输）事件序列的示例
|
Server A |
Server B |
|
Principal, Synchronized |
Mirror, Synchronized |
|
开始一个包含数据更新的多语句事务 |
|
|
主数据库的事务日志记录被放入事务日志缓冲区 |
|
|
事务日志缓冲区内容被写入磁盘（硬化），日志记录块被发送到镜像服务器，主服务器记录日志块的 mirroring_failover_lsn，然后等待镜像服务器的确认。 |
|
|
|
镜像服务器接收日志记录并放入事务日志缓冲区 |
|
|
镜像服务器将日志缓冲区输出到磁盘，记录 mirroring_failover_lsn，然后通知主服务器日志块已被硬化 |
|
主服务器接收日志记录已被镜像服务器硬化到磁盘的通知 |
镜像服务器继续重新执行REDO队列中的事务日志 |
|
包含了COMMIT的日志写入事务日志缓冲区 |
|
|
事务日志缓冲区内容被写入磁盘（硬化），
包含了COMMIT的日志记录块被发送到镜像服务器，主服务器记录日志块的 mirroring_failover_lsn，然后等待镜像服务器的确认。 |
|
|
|
镜像服务器接收日志记录并放入事务日志缓冲区 |
|
|
镜像服务器将日志缓冲区输出到磁盘，记录the mirroring_failover_lsn，然后通知主服务器日志块已被硬化 |
|
主服务器接收日志记录已被镜像服务器硬化到磁盘的通知，至此整个事务提交 |
镜像服务器继续重新执行REDO队列中包含了COMMIT的事务日志，修改数据页面 |
|
新事务被写入主服务器的日志缓冲区 |
|
以上事件序列中关键的一点就是：当 safety设置为FULL时，主服务器硬化日志缓冲区以及将日志缓冲区中日志记录的副本发送到镜像服务器，二者是同时进行的。然后主服务器开始等待自己的I/O以及镜像服务器的I/O，两个I/O都完成后才认为事务完成了。当主服务器接收到来自镜像的答复后，再开始处理下一次硬化。
当safety设置为FULL时，尽管主服务器和镜像服务器之间协调紧密，但是数据库镜像不是分布式事务，也不使用两阶段提交协议。
◆在数据库镜像中，两个事务分别在两台服务器上执行，并不是一个跨服务器的分布式事务。
假设使用safety FULL和见证服务器配置了数据库镜像。镜像服务器即Server B通过ping发现主服务Server A不可用。Server B与见证服务器通信并收到见证服务器也看不到Server A的确认消息。那么Server B将和见证服务器组成quorum并将自己提升为主服务器角色。它将恢复它的数据库并且通知见证服务器如今自己担当了主服务器的角色（尽管数据库处于disconnected状态，新主数据库的事务日志也不能被截断）。
Server B的新主数据库继续重新执行事务日志中的活动，但是它将持续redo状态而且大多数情况下只有很少的工作需要完成。在所有SQL Server版本中，新主数据库只要完成redo过程就立刻可用了。当数据库进入undo状态时将可以接收用户连接了。完成redo通常只需几秒钟，尽管余下的undo阶段时间可能很长。在数据库镜像中，新的主数据库只要redo阶段完成就可以为用户连接提供服务。新主服务器B的数据库处于DISCONNECTED状态而且是exposed，但是只要redo过程完成就可以提供数据库服务。
通常将整个应用程序从主服务器重新定向到新主服务器花费的时间要多于数据库镜像的自动故障转移。应用程序必须检测和重试连接，这样也会增加该过程的整体时间。此外，假如将新的SQL Server验证登陆账号添加到服务器，还需要使用系统存储过程sp_change_users_login将这些登陆账户映射到新主数据库的用户账户。假如旧的主服务器上一些关键对象，如SQL Agent作业还没有拷贝到新主服务器上，也会耽误应用程序故障转移的完成。（更多信息请阅读该白皮书实现数据库镜像部分的“为故障转移准备镜像服务器”）
现在假设旧的主服务器联机了。假如是手动故障转移，或者旧的主服务器被快速修复的自动故障转移场景，两台服务器需要进行角色互换，那么就必须进行一个协商过程。在数据库镜像重新开始之前，两台伙伴服务器需要决定彼此怎样进行同步。镜像故障转移lsn这个过程中扮演了一个关键角色。
Server A （新镜像服务器）落后了，但它并不清楚自己落后了多少。Server A向server B（新主服务器）报告它从server B接收的最后的镜像故障转移lsn。另一方面，Server B由于某些提交的工作而导致它有最新的镜像故障转移lsn，server A必须要追赶上server B。Server B将足够数量的事务日志发送给server A，使server A通过重新这些执行事务并与Server B同步。
手动故障转移
手动故障转移就是依次交换两个伙伴服务器的角色。它要求safety设置为FULL，并且主服务器和镜像服务器处于SYNCHRONIZED状态。
在主服务器上使用下面的ALTER DATABASE命令进行手动故障转移：
ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;
|
或者在Management Studio的Database Properties/Mirroring对话框中单击Failover按钮。手动故障转移在旧的主数据库上断开所有用户连接并回滚所有未完成的事务。通过完成所有redo队列中已提交的事务，回滚所有未完成的事务（在undo阶段）来恢复镜像数据库。旧的旧的镜像数据库被分配了主数据库角色，而旧的主数据库则担当新的镜像数据库角色。两台服务器根据它们的镜像故障转移lsn协商数据库镜像的新起点，然后处理角色互换。
可以使用手动故障转移作为实现操作系统或者SQL SERVER实例的‘滚动升级’的一种方式来，假如您在初始化镜像服务器之前首先升级镜像服务器。更多信息请参阅SQL Server Books Online中'Manual Failover' 主题。
Forced Service
在镜像服务器上使用ALTER DATABASE命令进行forced Service：
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;
|
通常只有当safety为OFF并且主服务器再也无法运转时才使用这种方式。也可以在safety为FULL使使用该命令，但是假如恢复的镜像服务器无法组成quorum，它也不能提供数据库服务。因此最好在safety为OFF（高性能操作模式）是使用该命令。由于异步的数据传输无法保证镜像数据库包含所有主服务器上提交的最新事务，因此有些数据可能会丢失。
数据库镜像可用性场景
在这一部分，您将根据以下两类事件对数据库镜像预期的可用性结果进行研究：
◆一个或多个服务器或者数据库失败
高可用场景中服务器失败
高可用操作模式下的数据库镜像其目的就是尽可能增加数据库的可用性。在这种模式下，假如主数据库无法访问，那么数据库镜像将迅速使镜像数据库可以接受访问。在下面的一组场景中，我们的讨论将从高可用配置加上三台独立的服务器开始。
在下面的高可用场景中，Server A作为主服务器启动，Server B是镜像服务器，而Server W是见证服务器，如图1所示：
图1：示例数据库镜像会话在高可用操作模式下启动
所有这三台服务器可以在同一个站点使用局域网连接，也可以在不同的站点使用WAN进行连接。Server A和Server B可以互换角色，但是Server W始终作为见证服务器。
现在来考虑假如其中一台服务器出现故障时产生的结果。
场景 HASL1.1：主服务器失败
下面的场景分析了在高可用模式下主服务器失败时会发生什么。图 2显示了不同的角色，以及镜像伙伴之间如何做角色转换。
图2：在高可用模式下，当主服务器Server A失败，故障转移发生
主服务器Server A失败后，镜像和见证服务器组成quorum，自动的故障转移产生。假如重新恢复了原始的主服务器，它将担当起镜像服务器的角色。
注意：要导致高可用模式下的故障转移，失败可以发生在不同的级别上：服务服务器可能停机、主服务器上的SQL SERVER实例可能停止或者失败、服务器上的主数据库可能不可用或状态可疑。在下面场景中，主服务器失败可能由这些事件中的任何一个引起。
因为Server B和W可以组成quorum，并且二者均无法联系Server A，那么Server B可以将自己提升为新的主服务器。但是假如没有镜像服务器，镜像会话就被认为是exposed。
Server A恢复后，它成为新的主服务器，镜像会话也不再是exposed。
单服务器失败事件并不多见，两台服务器失败就更少见了，因此研究在这种情况下出现的结果十分有用。
两台服务器可以同时或者几乎同时失败，但从数据库镜像的角度来看，其结果被视为一台服务器失败紧接着另一台也失败了。因此这些场景只考虑当多台服务器顺序失败时的后果。
接下来的两个场景分析主服务器 Server A失败，紧接着其他两台服务器也失败时会产生的结果。
◆新的主服务器 Server B失败；
场景 HASL1.3：主服务器失败，随后见证服务器失败
主服务器失败后发生故障转移。见证服务器可能接下来也失败，如图4所示：
图4：见证服务器紧随原始主服务器出现失败，那么新主服务器无法提供数据库服务
当见证服务器 Server W主服务器 Server A失败后也出现失败，那么新主服务器 Server B依然为主服务器但被孤立，无法组成quorum，也不能提供数据库服务。
假如Server A首先恢复，Server B的mirroring_role_sequence号将比Server A的大1，因为产生了故障转移。这些信息指示Server A如今Server B在Server A只有担当了主服务器的角色。Server A和Server B组成quorum 并成为一对镜像，此后两台服务器保持同步。除非Server W恢复，否则不会产生自动故障转移。
注意： 假如Server W在Server A和Server B相继之后也宣告失败，那么无论以什么次序恢复见证服务器，已经转换完成的Server A和Server B的角色将保持不变。
场景 HASL2.1：镜像服务器失败
假如镜像服务器首先失败，那么主服务器被视为exposed，因为它无法发送数据给镜像服务器。图 5显示了Server B，即镜像服务器失败时的行为。
图5：在高可用模式下，当镜像服务器Server B失败时不产生故障转移
没有自动故障转移发生，镜像伙伴也不会交换角色。当Server B恢复时，所有三台服务器还原到其初始角色和状态。
下表显示了镜像服务器Server B失败以及恢复时数据库状态。
由于没有镜像服务器，数据无法存放在冗余数据库中，因此会话处于exposed。
Server B一旦恢复立刻重新担当起它的镜像服务器角色。只要两台服务器同步，镜像会话就不再被视为exposed。
接下来的两个场景考虑镜像服务器Server B失败，紧接着主服务器Server A或者见证服务器Server W失败时产生的结果。
场景 HASL2.2：镜像服务器失败，随后主服务器失败
紧随镜像服务器之后主服务器也失败了，镜像伙伴服务器的角色保持不变。图6显示了采用不同方式还原服务器时角色将如何转换。
图6：镜像服务器失败随后主服务器主失败，那么见证服务器被孤立
在Server B和Server A都失败后，各服务器状态显示在图中的右上角处。 假如Server B首先恢复，它将从见证服务器Server W处检测到Server A依然为主服务器并且还没有产生故障转移，mirroring_failover_lsn也没有增加。其结果为，Server B依然为镜像服务器。Server W恢复后将会话还原到初始状态。
注意：假如Server W在Server B和Server A相继失败之后也宣告失败了，那么以任何顺序还原这些服务器将导致相同结果。
场景 HASL2.3：镜像服务器失败，随后见证服务器失败
镜像服务器失败，随后见证服务器也失败，那么主服务器被孤立并且无法和任何其他服务器组成quorum。因此它必须停止数据库的工作，如图7右上角所示。
图7：A镜像服务器失败，随后见证服务器失败，导致主服务器无法提供数据库服务
由于镜像服务器故障以及随后的见证服务器失败，主服务器 Server A保持其主服务器角色，由于无法和任何其他服务器组成quorum，而safety又被设置成FULL，因此不再为数据库提供服务，并断开所有的用户连接。
假如Server B首先恢复，那么数据库镜像将重新开始工作，尽管由于缺失见证服务器而不会产生自动故障转移。
假如Server W首先恢复，那么情况与图5中显示的一样。
注意：假如Server A在Server B和Server W相继失败之后也宣告失败，那么以任何次序还原这些服务器其最终结果保持不变。
场景 HASL3.1：见证服务器失败
见证服务器失败时，数据库镜像继续进行但是不可能产生自动的故障转移。假如再有一台或多台服务器失败，就意味着没法组成quorum，那么主服务器上的数据库也不再服务于数据库用户。
图8：在高可用模式下，见证服务器Server W首先失败，那么数据库镜像继续
Server W恢复后，两个伙伴服务器Server A和Server B维持它们的初始角色。
下表显示了见证服务器失败以及恢复后，数据库状态以及quorum的变化。
下面的两个场景考虑见证服务器Server W失败，紧接着主服务器 Server A或者镜像服务器Server B失败时产生的结果。
场景 HASL3.2：见证服务器失败，随后主服务器失败
见证服务器首先失败，那么数据库镜像将继续进行，但是不可能产生自动的故障转移。其余两台服务器中任何一台失败将导致无法组成quorum，余下的那台服务器将被孤立。
图9：原始见证服务器失败，随后主服务器失败，镜像伙伴角色保持不变
假如Server W首先恢复，那么Server B将从见证服务器那里检测到最后的主服务器是Server A，同时Server B依然是镜像服务器。最终Server A恢复时，它将保持其主服务器角色。
注意： 假如Server B在Server W和Server A相继失败后也宣告失败了，那么以任意次序还原这些服务器都不会影响最终结果。
场景 HASL3.3：见证服务器失败，随后镜像服务器失败
假如见证服务器失败，随后镜像服务器也失败，那么主服务器被孤立。由于safety设置为FULL并且主服务器无法组成quorum，它将不再提供数据库服务，如图10所示。
图10：见证服务器失败，随后镜像服务器失败，主服务器必须停止其数据库服务
注意： 假如Server A在Server W和Server B相继失败之后也宣告失败， 那么以任意次序还原这些服务器都不会影响最终结果。
总结：高可用场景中服务器失败
从这些场景中可以得出几个结论。在高可用操作模式下：
1.假如主服务器首先不可用，那么产生自动的故障转移，原先的镜像服务器将担当主服务器角色，并使其数据库服务于用户活动。后续的服务器失败和恢复不会影响使用新主服务器的数据库镜像的整体配置。数据库镜像将以相反的方向继续进行。
因为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继续接受事务但无法截断事务日志记录。假如迅速恢复了链路，镜像会话还可以重新同步并返回到初始操作状态。
总结：见证服务器和主服务器位于同一站点，镜像服务器位于远程站点，站点之间的通信中断不会产生自动的故障转移。
总结：高可用场景中通信连路中断
在使用三台独立服务器的高可用配置中，有三条独立的通信连路。
◆主服务器/镜像服务器出现通信失败，没有自动的故障转移会发生。
场景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时间（秒） =
测试数据库镜像
当设置自己的系统来测试数据库镜像时，有许多选项可用。所有数据库镜像都要求在数据库镜像会话中的服务器必须是不同的SQL SERVER实例。因此可以在一台物理服务器上配置和测试数据库镜像，假如您安装了多个SQL SERVER 2005关系数据库引擎。也可以在一台虚拟服务器上测试多个实例，但是在物理服务器上进行测试更加可信。
进行数据库镜像的负载和压力测试时需要不同的物理服务器。一台服务器上的两个或者三个实例可能会消耗不切实际的服务器资源。此外服务器之间的网络连接质量也同样重要。主服务器和镜像服务器之间的网络越好，日志记录和消息传送的速度就越快。
最逼真的测试就是在一台真正的目标服务器或者试验台上进行，并且和最终系统的物理属性完全相同。当您在一台服务器上测试多个实例时，只能通过停止实例或者关机的方式来模拟数据库镜像中服务器失败的效果。使用多台物理服务器时，就可以通过断开网线的方式来测试网络连接失败的效果。
下面的实践能够帮助您创建测试环境：
◆要测试服务器失败，关闭SQL SERVER实例，通过SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。
数据库镜像和群集
数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余。数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 SQL SERVER实例，两个实例有不同的名称；而群集中的 SQL SERVER实例则使用相同的虚拟服务器名称和IP地址，而且无论哪个节点主持群集实例，虚拟服务器名称和IP地址始终保持不变。
假如您需要在服务器一级的数据库保护（例如，您的应用程序需要同时访问统一服务器上的多个数据库），故障转移群集将是更适合的选择。但是，假如每次只须为一个数据库提供可用性，那么数据库镜像具有更多优势。
数据库镜像不像群集那样需要专门的硬件，也没有共享存储介质失败的潜在危险。数据库镜像可以在最短时间内让备用数据库开始提供服务，其速度快于任何其它的高可用技术。此外，数据库镜像能够与ADO。NET和SQL Native Access Client很好的配合在一起，从而实现客户端的故障转移。
不能在群集中使用数据库镜像，但是可以考虑使用数据库镜像作为一种手段来创建群集数据库实例的一个热备用份。这样做需要特别小心，因为群集的故障转移时间长于数据库镜像的超时值，高可用模式下的镜像会话将对群集的故障转移做出反应，认为这是主服务器失败了，然后会将群集节点设置为镜像状态。
内容列表
概述 可以在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：
SELECT * 注意数据库镜像会话中的每个伙伴保存的所有元数据从另一个伙伴的角度来看是完全相同的。每个伙伴保存其数据库名称、整个会话的safety设置、数据库的镜像状态、以及两个序列计数器。
◆mirroring_safety_sequence计数器保存在两个伙伴上，只要safety设置改变时将增加该计数器的值。 由于见证服务器状态真正记录在伙伴服务器而不是见证服务器上，因此这些状态是从有利于伙伴的角度来设置的，因此当您看到见证服务器为DISCONNECTED状态时，意味着伙伴和见证服务器断开了。数据库镜像启动后，假如镜像服务器无法与主服务器进行初始化，那么见证服务器进入UNKNOWN状态。
传输事务日志记录
SQL Server主服务器和镜像服务器传输消息和日志记录的次序根据事务安全性的设置而不同。我们先研究同步传输，然后再研究异步传输。
当SQL Server将事务事件记录在事务日志中时，日志记录被写入磁盘前暂时存放在日志缓冲区中。 数据库镜像时，每次日志缓冲区被输出到硬盘时（硬化），主服务器也将相同的日志记录块发送到镜像服务器。
1. 当safety设置为FULL，只要SQL Server主服务器硬化它的日志记录块，就同时将相同的日志记录块发送到镜像服务器，并认为本地的日志I/O和远程镜像服务器的日志I/O从本质上来说是一样 的。这种传输称为同步的，因为在一个事务提交之前，主服务器既要等待本地的I/O（硬化）还要等待等待镜像服务器有关完成I/O（硬化）的答复。
每次主服务器或者镜像服务器硬化日志缓冲区时，都会将缓冲区中最高的日志序列号（LSN）+ 1作为mirroring_failover_lsn记录在元数据中。
mirroring_failover_lsn用于协商事务日志最后的保障点，这样两个伙伴数据库就可以在初始化时保持同步，在故障转移后也保持同步。
当主服务器发送日志记录给镜像服务器时，主服务器上的mirroring_failover_lsn通常会提前一些。镜像服务器硬化日志记录时会记录其mirroring_failover_lsn，然后回复主服务器。但是等主服务器接收到来自镜像的确认信息时，主服务器可能已经开始硬化新的一组日志记录了。
表8显示了主服务器和镜像服务器safety为FULL时的一个事件序列示例。
表8：Safety为FULL （同步传输）事件序列的示例
|
Server A |
Server B |
|
Principal, Synchronized |
Mirror, Synchronized |
|
开始一个包含数据更新的多语句事务 |
|
|
主数据库的事务日志记录被放入事务日志缓冲区 |
|
|
事务日志缓冲区内容被写入磁盘（硬化），日志记录块被发送到镜像服务器，主服务器记录日志块的 mirroring_failover_lsn，然后等待镜像服务器的确认。 |
|
|
|
镜像服务器接收日志记录并放入事务日志缓冲区 |
|
|
镜像服务器将日志缓冲区输出到磁盘，记录 mirroring_failover_lsn，然后通知主服务器日志块已被硬化 |
|
主服务器接收日志记录已被镜像服务器硬化到磁盘的通知 |
镜像服务器继续重新执行REDO队列中的事务日志 |
|
包含了COMMIT的日志写入事务日志缓冲区 |
|
|
事务日志缓冲区内容被写入磁盘（硬化），
包含了COMMIT的日志记录块被发送到镜像服务器，主服务器记录日志块的 mirroring_failover_lsn，然后等待镜像服务器的确认。 |
|
|
|
镜像服务器接收日志记录并放入事务日志缓冲区 |
|
|
镜像服务器将日志缓冲区输出到磁盘，记录the mirroring_failover_lsn，然后通知主服务器日志块已被硬化 |
|
主服务器接收日志记录已被镜像服务器硬化到磁盘的通知，至此整个事务提交 |
镜像服务器继续重新执行REDO队列中包含了COMMIT的事务日志，修改数据页面 |
|
新事务被写入主服务器的日志缓冲区 |
|
以上事件序列中关键的一点就是：当 safety设置为FULL时，主服务器硬化日志缓冲区以及将日志缓冲区中日志记录的副本发送到镜像服务器，二者是同时进行的。然后主服务器开始等待自己的I/O以及镜像服务器的I/O，两个I/O都完成后才认为事务完成了。当主服务器接收到来自镜像的答复后，再开始处理下一次硬化。
当safety设置为FULL时，尽管主服务器和镜像服务器之间协调紧密，但是数据库镜像不是分布式事务，也不使用两阶段提交协议。
◆在数据库镜像中，两个事务分别在两台服务器上执行，并不是一个跨服务器的分布式事务。 假如Server B首先恢复，它将从见证服务器Server W处检测到Server A依然为主服务器并且还没有产生故障转移，mirroring_failover_lsn也没有增加。其结果为，Server B依然为镜像服务器。Server W恢复后将会话还原到初始状态。
注意：假如Server W在Server B和Server A相继失败之后也宣告失败了，那么以任何顺序还原这些服务器将导致相同结果。
场景 HASL2.3：镜像服务器失败，随后见证服务器失败
镜像服务器失败，随后见证服务器也失败，那么主服务器被孤立并且无法和任何其他服务器组成quorum。因此它必须停止数据库的工作，如图7右上角所示。
图7：A镜像服务器失败，随后见证服务器失败，导致主服务器无法提供数据库服务
由于镜像服务器故障以及随后的见证服务器失败，主服务器 Server A保持其主服务器角色，由于无法和任何其他服务器组成quorum，而safety又被设置成FULL，因此不再为数据库提供服务，并断开所有的用户连接。
假如Server B首先恢复，那么数据库镜像将重新开始工作，尽管由于缺失见证服务器而不会产生自动故障转移。
假如Server W首先恢复，那么情况与图5中显示的一样。
注意：假如Server A在Server B和Server W相继失败之后也宣告失败，那么以任何次序还原这些服务器其最终结果保持不变。
场景 HASL3.1：见证服务器失败
见证服务器失败时，数据库镜像继续进行但是不可能产生自动的故障转移。假如再有一台或多台服务器失败，就意味着没法组成quorum，那么主服务器上的数据库也不再服务于数据库用户。
图8：在高可用模式下，见证服务器Server W首先失败，那么数据库镜像继续
Server W恢复后，两个伙伴服务器Server A和Server B维持它们的初始角色。
下表显示了见证服务器失败以及恢复后，数据库状态以及quorum的变化。
下面的两个场景考虑见证服务器Server W失败，紧接着主服务器 Server A或者镜像服务器Server B失败时产生的结果。
场景 HASL3.2：见证服务器失败，随后主服务器失败
见证服务器首先失败，那么数据库镜像将继续进行，但是不可能产生自动的故障转移。其余两台服务器中任何一台失败将导致无法组成quorum，余下的那台服务器将被孤立。
图9：原始见证服务器失败，随后主服务器失败，镜像伙伴角色保持不变
假如Server W首先恢复，那么Server B将从见证服务器那里检测到最后的主服务器是Server A，同时Server B依然是镜像服务器。最终Server A恢复时，它将保持其主服务器角色。
注意： 假如Server B在Server W和Server A相继失败后也宣告失败了，那么以任意次序还原这些服务器都不会影响最终结果。
场景 HASL3.3：见证服务器失败，随后镜像服务器失败
假如见证服务器失败，随后镜像服务器也失败，那么主服务器被孤立。由于safety设置为FULL并且主服务器无法组成quorum，它将不再提供数据库服务，如图10所示。
图10：见证服务器失败，随后镜像服务器失败，主服务器必须停止其数据库服务
注意： 假如Server A在Server W和Server B相继失败之后也宣告失败， 那么以任意次序还原这些服务器都不会影响最终结果。
总结：高可用场景中服务器失败
从这些场景中可以得出几个结论。在高可用操作模式下：
1.假如主服务器首先不可用，那么产生自动的故障转移，原先的镜像服务器将担当主服务器角色，并使其数据库服务于用户活动。后续的服务器失败和恢复不会影响使用新主服务器的数据库镜像的整体配置。数据库镜像将以相反的方向继续进行。
2.假如镜像首先不可用，那么产生自动的故障转移 。后续的服务器失败以及恢复次序都不会影响镜像伙伴角色。
3.假如见证服务器首先不可用，那么不可能产生自动的故障转移，镜像伙伴服务器将保持其初始角色。后续的服务器失败以及恢复都不会影响镜像伙伴角色。
下表总结了在高可用场景中出现一台或两台服务器失败时产生的结果。表中假设的条件是safety设置为FULL并且镜像会话中的服务器满足下列条件：
A：主服务器， SYNCHRONIZED
B：镜像服务器，SYNCHRONIZED
W：见证服务器，CONNECTED
表中使用灰色加亮显示故障转移场景。
表10：总结：单服务器或者双服务器失败，显示伙伴服务器角色和数据库状态
高可用场景中通信失败
高可用操作模式需要三个SQL Sever实例。假如这些服务器位于两个或三个独立的物理站点并且相距很远，那么这些站点间的通信就很可能出现问题。换句话说，服务器依然运转但是彼此间的通信连路中断了。这种情况比前面的那些场景要复杂一些，但原理是一样的。
下面高可用操作场景中通信失败的研究将通过两组来完成。第一组是基于三个来自不同站点的SQL SERVER实例，因此有三条独立的通信连路。第二组是基于两个独立站点上的服务器，第一个站点上的一对服务器和第二个站点上的第三台服务器之间有一条通信连路。
先从第一组开始，假设一个数据库会话中所有三台服务器之间有三条独立的通信连路。例如，主服务器、镜像服务器和见证服务器位于三个独立的协作站点上（也有可能三台服务器位于同一个站点，但使用私有网络连接）
初始条件是Server A上运行主数据库并且与其镜像伙伴Server B保持同步。
Server B上是镜像数据库Safety设置为FULL，见证服务器 (Server W)也包含在数据库镜像会话中。图11显示了初始配置。
图11：高可用配置中三台独立服务器、三条独立通信连路的初始状态
注意：要获得页面上图表的解释，请参阅前面介绍的“高可用场景中服务器失败”
根据图11，三条链路可能首先中断：A/B， A/W和B/W。注意当某条通信连路中断时，所有三台服务器依然运转正常。只有主服务器和镜像服务器之间的通信连路有一些影响，如表11所示。
表11：总结：单条通信连路中断
|
初始条件 |
事件 |
Quorum |
结果 |
条件 |
|
A： 主服务器， SYNCHRONIZED
B： 镜像服务器， SYNCHRONIZED
W： 见证服务器，
CONNECTED |
A/B连路中断
|
A和W |
A上的数据库提供服务， exposed |
A： 主服务器， DISCONNECTED
B： 镜像服务器， DISCONNECTED
W： 见证服务器，
CONNECTED |
|
A/W |
A和B |
A上的数据库提供服务 |
A： 主服务器， SYNCHRONIZED
B： 镜像服务器， SYNCHRONIZED
W： 见证服务器，
CONNECTED |
|
B/W |
A和B |
A上的数据库提供服务 |
A： 主服务器， SYNCHRONIZED
B： 镜像服务器， SYNCHRONIZED
W： 见证服务器，
CONNECTED |
只有主服务器/镜像服务器的连接中断会对镜像造成影响。其他的连路中断，例如主服务器/见证服务器或者镜像服务器/见证服务器之间的通信中断不会改变数据库镜像会话的行为。
总之，表HACL1显示出：
◆所有单条链路中断场景中只有主服务器/镜像服务器链路中断会影响数据库镜像，主服务器运行 状态为exposed，因为没有日志记录发送到镜像。
现在考虑假如第二条连路中断产生的结果。两条连路可以同时中断，也可以相继中断。
假如两条连路同时中断，其最终结果与两条连路相继中断是一样的。但是无法事先预料中断的先后顺序；只有知道了先后次序才能够据此分析链路同时中断的结果。
由于这个原因，我们只考虑链路顺序中断的情形。表12列出了高可用模式中通信链路中断的一些基本场景。
表12：大部分双-通信链路中断的结果与服务器故障场景中单机故障是一样的
|
场景 |
第一条连路中断 |
场景 |
第一条连路中断 |
结果 |
其余服务器的等价场景 |
参阅场景 |
|
HACL1.1 |
A/B |
HACL1.2 |
A/W |
Server A被孤立 |
Server A停机 |
无 |
|
|
|
HACL1.3 |
B/W |
Server B 被孤立 |
Server B 停机 |
HASL2.1 |
|
HACL2.1 |
A/W |
HACL2.1 |
A/B |
Server A 被孤立 |
Server A 停机 |
HASL1.1 |
|
|
|
HACL2.2 |
B/W |
Server W 被孤立 |
Server W 停机 |
HASL3.1 |
|
HACL3.1 |
B/W |
HACL3.1 |
A/W |
Server W 被孤立 |
Server W 停机 |
HASL3.1 |
|
|
|
HACL3.2 |
A/B |
Server B 被孤立 |
Server B 停机 |
HASL2.1 |
表HACL2显示所有顺序的双-通信链路失败都等价于前一部分介绍的单服务器故障场景，因此我们不再这里对它们作重复分析了。
值得注意的一点是：
◆两条链路中断时只有一个场景会产生故障转移：主服务器/见证服务器链路中断，随后主服务器/镜像服务器链路中断。
假如主服务器/镜像服务器链路中断，随后主服务器/见证服务器也出现链路中断，那么不会产生故障转移，即使主服务器被孤立而且镜像服务器和见证服务器无法联系上它。
我们再仔细研究一下场景 HACL1.2。
场景 HACL1.2：主服务器/镜像服务器连路中断，随后主服务器/见证服务器链路中段
假如主服务器/镜像服务器链路中段，随后主服务器和见证服务器之间的链路也中断了，那么主服务器被孤立。它看不到其他服务器并且失去了它的quorum。同时，镜像服务器和见证服务器无法知道主服务器是否依然健在，因此Server B担当起主服务器，然后自动的故障转移产生。图12显示了这些事件。
图12：在高可用模式下， 主服务器/镜像服务器链路中段，随后主服务器/见证服务器链路中段，不产生故障转移
当主服务器/镜像服务器以及主服务器/见证服务器之间的通信链路相继中断有，Server A被孤立并使其数据库停止服务。Server B和W无法形成quorum，因为Server A可能执行了一些Server B上没有的工作。
假如主服务器/见证服务器 (A/W) 链路中断首先修复，那么Server A继续担当其主服务器角色，状态为DISCONNECTED。但是不会进行数据库镜像，因为主服务器和镜像服务器之间的连接还没有修复。
假如主服务器/镜像服务器 (A/B) 链路中断首先修复，那么Server A将继续与Server B的数据库竞相，即使没有见证服务器，因此该会话是exposed。除非主服务器/见证服务器连接最终被修复，否则不会产生自动的故障转移。
总结：高可用场景中通信失败：三个站点
下表总结了使用三台独立物理服务器时单链路和双-链路中断的行为。
表中的初始条件是Safety设置为FULL，服务器分别是：
A：主服务器， SYNCHRONIZED
B：镜像服务器， SYNCHRONIZED
W：见证服务器， CONNECTED
使用灰色加亮显示故障转移路径。
表13：总结：单条链路中断和双-链路中断，高可用模式，三台独立服务器，Safety设置为FULL
场景 HACL4：两个站点，见证服务器位于镜像服务器站点
假如所有服务器之间仅有一条通信连路，那么必须选择见证服务器的位置。首先，假设见证服务器和镜像数据库服务器放置在一起。两组服务器之间仅有一条通信连路，该链路可能中断，如图13所示。
图13：主服务器和镜像服务器/见证服务器站点之间的通信连路中断了
Server A看不到见证服务器Server W或者镜像数据库服务器Server B，因此无法组成quorum。 Server B和Server W可以组成quorum，但二者均无法看见主服务器Server A。链路中断的结果显示在图14。
图14：通信连路中断并且见证服务器位于镜像服务器站点，产生故障转移
因为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：
SELECT * FROM sys.database_mirroring_endpoints; |
确认使用了正确的完全限定计算机名称以及正确的端口号。假如在一台物理服务器的多个实例之间配置镜像，那么端口号就必须是唯一的。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但没有见证服务器），镜像服务器又断开了和旧的主服务器的联系。可以在镜像服务器上使用下面的命令强制镜像服务器进行恢复：
ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS |
问题就在于一旦恢复了镜像数据库，镜像服务器将成为主服务器但却无法形成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高可用性技术
|
类别 |
可用性功能 |
数据库镜像 (HA模式) |
故障转移群集 |
日志传送 |
事务复制 |
|
故障转移特性 |
备用服务器类型 |
Hot |
Hot |
Warm |
Hot |
|
自动角色转换 |
是 |
是 |
需要自己编写代码 |
需要自己编写代码 |
|
故障转移保留已提交的工作 |
是 |
是 |
否 |
否 |
|
故障转移类型 |
自动和手动 |
自动和手动 |
|
|
|
故障转移过程数据库停工时间 |
少于10秒 |
30秒+ 数据库还原 |
可变的 |
可变的 |
|
物理配置 |
冗余的存储位置 |
是 |
否（共享磁盘） |
是 |
是 |
|
硬件需求 |
标准服务器 |
群集验证的服务器和存储 |
标准服务器 |
标准服务器 |
|
物理距离限制 |
没有 |
100米 |
没有 |
没有 |
|
其它服务器角色 |
见证服务器 |
没有 |
监视服务器 |
分发服务器 |
|
管理 |
复杂性等级 |
低 |
高 |
低 |
中等 |
|
备用服务器的可访问性 |
通过数据库快照，性能可能受到影响 |
不可访问 |
R/O但是与数据库还原不兼容 |
允许只读工作 |
|
多备用服务器 |
无 |
无 |
是 |
是 |
|
备用服务器加载延迟 |
没有 |
没有 |
有延迟 |
没有 |
|
可用性范围 |
数据库 |
服务器实例 |
数据库 |
数据库 |
|
客户访问 |
客户重定向 |
由ADO。NET和 SQL Native Client提供支持 |
不需要，使用虚拟IP |
需要自己编写代码 |
需要自己编写代码 |
上表总结了所有四种高可用技术的特性。下一部分将进行更详细的比较。
数据库镜像和群集
数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余。数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 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提供的高可用技术家族中的新成员。
更多信息请参阅：
SQL SERVER TechNet站点： http：//www.microsoft.com/technet/prodtechnol/sql
SQL SERVER开发人员站点： http：//msdn.microsoft.com/sql
Microsoft SQL SERVER站点： http：//www.microsoft.com/sql/
| | 
