1. 备份主数据库的尾日志(如果可能的话)

　　通常，发生故障的时候，主数据库与辅助数据库是不同步的，因为主数据库在其最近的备份作业后会继续有更新。此外，在某些情况下，主服务器上最新的日志备份尚未复制到辅助服务器中，或者某些已复制的日志备份可能尚未应用到辅助数据库中。因此首先要将辅助数据库与主数据库同步。

　　此时，如果此时主数据库还是可以访问的话，你需要手工对主数据库做一个日志备份，也就是备份“尾日志”，这样就获得了最后一次备份作业执行之后所有数据更新。建议使用withnorecovery参数来备份尾日志，这样使得主数据库处于还原状态，保证在做故障转移的时候不会有新的数据更新进入主数据库，可以确保主数据和辅助数据库的同步。

　　接下来，把主服务器的共享目录中所有未被复制的备份文件，连同尾日志备份，复制到所有辅助服务器上日志传送所用的本地目录中。

　　2. 在辅助服务器上，通过检查还原作业的历史信息，可以知道最后一个被还原的日志备份是哪个。然后，要将所有未还原的事务日志备份按顺序还原到所有辅助数据库上。这样，数据同步的工作就完成了。

　　3. 同步辅助服务器之后，你可以选择恢复辅助数据库来作为故障转移的目标数据库。对该辅助数据库执行恢复操作(restoredatabase… with recovery)，恢复操作将使数据库处于一致的状态并使其联机。然后删除辅助服务器上的复制作业和还原作业，故障转移就完成了。

　　4. 日志传送只同步用户数据库的内容，但不会同步保存在master数据库中的登录信息。要使得应用可以使用新的主数据库，你需要手动把登录信息从原始的主服务器实例迁移到新的主服务器实例上。在新的主服务器上建立登录，除了要保证登录名和密码要和原始的主服务器一致之外，还要保证登录名对应的SID也一致;否则该登录名就无法被正确映射成为新的主数据库中的用户，导致应用依旧无法使用数据库。

　　5. 最后你需要通过修改连接字符串，使用别名等方法把应用重定向到新的主服务器上。至此一个日志传送的“故障切换”就大功告成了。

　　可以看到日志传送的故障转移操作起来是比较麻烦的，需要一定的时间来完成。操作人员需要很熟悉整个过程。因此日志传送不是一个好的高可用性方案，它更多的作为一个灾难恢复的方案，为主数据库提供一个或多个副本来作为保障。

　　恢复辅助数据库之后，它就成为了新的主数据库。当故障服务器(原先的主服务器)修复后，你可以重新配置日志传送，让原先的辅助数据库开始扮演主数据库的角色，而原先故障的主数据库转为扮演辅助数据库。(日志传送的故障切换是单向的，不提供自动地将主数据库转换角色的功能。)

　　(1) 如果原先的主数据库已经完全不可用，就必须完全重建日志传送，在重建时把原先的主服务器选择为新的辅助服务器。

　　(2) 如果原先的主数据库还可以访问，只需执行以下步骤就可以比较快速地交换主数据库和辅助数据库的角色。

　　a. 确保已经使用了with norecovery备份过了原始主数据库上的尾日志(见故障转移流程的步骤1)。

　　b. 删除原先的主服务器上的日志传送备份作业以及原先的辅助服务器(现在的主服务器)上的复制和还原作业。

　　c. 使用 SQL Server ManagementStudio 在原始的辅助数据库(要用作新的主数据库的数据库)上配置日志传送。要注意以下步骤：

　　添加辅助数据库时，在“SecondaryDatabase Settings”对话框的“Secondary database”框中输入原先的服务器上的主数据库的名称。

　　在“Initialize SecondaryDatabase”对话框中，选中“No, the secondary database isinitailizaed”。无论是原始的主数据库是否还可用，在交换角色的过程中，都建议使用与切换之前相同的共享文件夹来存放新的主数据库的日志备份。这样做的好处是，如果原始的日志传送配置中有多个辅助服务器的话，其余那些没有参与角色交换的辅助服务器，依旧可以通过原本配置的复制作业和还原作业，继续和新的主数据库同步。