项目
04/01/2012

强制服务（可能造成数据丢失）

数据库镜像提供强制服务（可能造成数据丢失）作为灾难恢复方法，以允许将镜像服务器用作备用服务器。仅当主体服务器在镜像会话中与镜像服务器断开连接时，才能强制服务运行。因为强制服务运行存在数据丢失的风险，所以应该谨慎使用。

是否支持强制服务取决于会话的运行模式和状态，如下所示：

通常，当主体服务器断开连接时，高性能模式支持强制服务。但是，高性能模式会话可能存在见证服务器（虽然并非必需）。在这种情况下，强制服务要求镜像服务器和见证服务器相互连接。
当主体服务器断开连接时，不带自动故障转移功能的高安全性模式支持强制服务。
当镜像服务器和见证服务器相互连接并且它们都未连接到主体服务器时，具有自动故障转移功能的高安全性模式支持强制服务（只要当镜像服务器上次连接到主体服务器时，不回滚镜像数据库）。

建议仅当您必须立即还原数据库服务并愿意承担数据丢失的风险时，才能强制服务运行。强制服务的结果相当于删除镜像，但强制服务在恢复镜像时便于重新同步数据库，并且可能存在数据丢失的风险。强制服务将把主体角色平滑转换给镜像数据库。镜像服务器将担当主体服务器角色并立即向客户端提供数据库的副本。新的主体数据库在没有镜像的情况下运行（即公开运行）。

重要提示
如果主体服务器仅与数据库镜像会话断开连接并且仍在运行，则某些客户端可以继续访问原始主体数据库。强制服务之前，必须防止客户端访问原始主体服务器。否则，强制服务之后，原始主体数据库和当前主体数据库便会分别进行更新。

强制服务的典型事例

下图说明了强制服务（可能造成数据丢失）的典型事例。

可能会丢失数据的强制服务

在图中，原始主体服务器 Partner_A 不可用于镜像服务器 Partner_B，从而导致镜像数据库断开连接。确定 Partner_A 不可用于客户端之后，数据库管理员对 Partner_B 进行强制服务，这可能会造成数据丢失。Partner_B 变为主体服务器，并在数据库“公开”（也就是未镜像）的情况下运行。此时，客户端可以重新连接到 Partner_B。

当 Partner_A 变得可用时，它会重新连接到新的主体服务器，从而重新加入会话并担当镜像角色。镜像会话便会立即挂起，而尚未同步新的镜像数据库。会话挂起之后，数据库管理员可以确定是恢复会话，还是在极特殊情况下删除镜像并尝试对以前主体数据库中的数据进行补救。在此事例中，数据库管理员选择恢复镜像。此时，Partner_A 接管镜像服务器的角色并将以前的主体数据库回滚到上次成功同步事务的时间点；如果在强制服务之前，未将所有提交的事务写入镜像服务器上的磁盘，则这些事务将丢失。然后，Partner_A 通过应用自以前镜像服务器变为新主体服务器以来对新主体数据库所做的所有更改，前滚新的镜像数据库。

注意
虽然高性能模式不需要见证服务器，但如果配置了一个见证服务器，则仅当见证服务器当前连接到镜像服务器时，才可以强制服务运行。

强制服务的风险

一定要注意，强制服务可能会造成数据丢失。数据可能会丢失，因为镜像服务器无法与主体服务器进行通信，从而不能保证两个数据库同步。强制服务还启动新的恢复分叉。由于原始主体数据库和镜像数据库位于不同的恢复分叉，因此，现在每个数据库都包含另一个数据库所没有的数据：原始主体数据库包含尚未从其发送队列发送到以前的镜像数据库的所有更改（未发送日志）；以前的镜像数据库包含强制服务后所做的所有更改。

注意
有关恢复分支的详细信息，请参阅恢复路径。

如果因为主体服务器出现故障而强制服务，则潜在的数据丢失取决于是否在出现故障之前已将所有事务日志发送到镜像服务器。在高安全性模式下，可能仅在镜像数据库同步之前会出现这种情况。在高性能模式下，可能会始终存在累积的未发送日志。

强制服务的影响在某种程度上取决于会话是否具有见证服务器：

没有见证服务器时，如果伙伴断开连接（例如，因为伙伴网络连接断开），则可以强制服务运行。如果原始主体服务器仍在运行，则两个伙伴都拥有主体角色。连接到新主体服务器的客户端将访问当前版本的数据库，而连接到原始主体服务器的客户端将访问原始主体数据库。这种情况增大了数据丢失的可能性。如果允许伙伴进行重新连接，则原始主体服务器担当镜像角色，并在镜像挂起之前将其数据库的状态更改为“正在恢复”。如果恢复会话，则原始主体数据库中日志在最近断开连接以来已在发送队列中的事务将丢失。此外，强制服务之后发生的所有事务也将丢失。
存在见证服务器时，如果镜像服务器与主体服务器和见证服务器断开连接，则只要主体服务器和见证服务器保持相互连接，主体服务器便会公开运行。如果主体服务器与见证服务器断开连接，则它会停止为数据库提供服务。此后，如果镜像服务器重新连接到见证服务器，则可以强制服务运行。如果强制服务，则在重新连接原始主体服务器时，在原始主体服务器公开运行时所做的所有更改都将丢失。

有关详细信息，请参阅本主题后面的“管理潜在的数据丢失”部分。

管理潜在的数据丢失

强制服务之后，如果以前的主体服务器可用，并假设其数据库没有损坏，则可以尝试管理潜在的数据丢失。管理潜在数据丢失的可用方法取决于原始主体服务器是否已重新连接到其伙伴并重新加入镜像会话。假设原始主体服务器可以访问新的主体实例，则会自动透明地进行重新连接。

已重新连接原始主体服务器

通常，出现故障后，原始主体服务器在重新启动时便会迅速重新连接到其伙伴。重新连接后，原始主体服务器变为镜像服务器。其数据库变为镜像数据库，并且在会话挂起之前进入恢复状态。除非恢复镜像，否则不回滚镜像数据库。

但是，无法访问恢复数据库；因此，不能对其进行检查以确定恢复镜像时可能丢失的数据。因此，确定是恢复镜像还是删除镜像取决于您是否能够完全接受数据丢失。

如果数据丢失不可接受，则应该删除镜像以对数据进行补救。

通过删除镜像，数据库管理员可以恢复原始主体数据库，并尝试恢复可能已丢失的数据。但是，如果以前的镜像数据库在线，则以前的伙伴将为同名的不同数据库提供服务。数据库管理员需要使客户端无法访问其中一个数据库，以免数据库产生进一步分歧并防止出现客户端故障转移问题。
如果数据丢失可以接受，则可以恢复镜像。

恢复镜像会导致新的镜像数据库如同步数据库第一步所述那样回滚。如果出现故障时日志记录在发送队列中等待，则相应的事务将会丢失，即使已提交这些事务也会如此。

尚未重新连接原始主体服务器

如果可以暂时阻止原始主体服务器通过网络重新连接到新的主体服务器，则可以检查原始主体数据库以确定恢复镜像时可能丢失的数据。

如果潜在的数据丢失可以接受

允许原始主体服务器重新连接到其伙伴。重新连接会导致镜像挂起。若要继续镜像，只需恢复会话。以前的主体服务器担当镜像角色。新的镜像服务器会删除原始恢复分叉，从而丢失从未发送到以前的镜像服务器或由其接收的所有事务。
如果数据丢失不可接受

如果原始主体数据库包含在恢复会话时可能丢失的重要数据，则可以删除镜像以保留原始主体服务器中的数据。建议在此时尝试备份主体数据库的日志尾部。然后，通过从原始主体数据库中导出要补救的数据，并将其导入当前主体数据库来更新当前主体数据库（以前的镜像数据库）。建议尽快对已更新的数据库执行完整数据库备份。

若要使用已更新的数据库作为初始主体数据库来重新建立镜像，请使用此备份（以及至少一个后续日志备份）创建新的镜像数据库。必须应用删除镜像之后执行的每个日志备份。因此，建议在启动新的镜像会话之前延迟主体数据的其他日志备份。