场景 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相继失败之后也宣告失败， 那么以任意次序还原这些服务器都不会影响最终结果。