在角色切换后管理登录名和作业

只能镜像主体数据库中的内容。无法镜像 master 或 msdb 系统数据库中的关联信息。此类关联信息包括针对主体数据库设置的作业以及向主体服务器添加的登录名。

如果此类信息对于支持角色切换非常重要，则应该在镜像站点重复此信息。如果可能，角色切换后最好在新主体数据库中以编程方式重新生成此信息。最常见的问题是登录名和作业。

登录名

对于在角色切换后能够访问数据库的用户来说，还必须在镜像服务器上进行定义在主体服务器上具有访问主体数据库权限的登录名。但是，无法镜像 master 数据库。因此，如果在当前主体服务器上为主体数据库的此登录名创建了一个新的登录名，则必须在镜像服务器上执行相同的操作。

必须在镜像服务器和主体服务器上手动定义数据库每个用户的登录名。否则，如果主体角色切换，并且以前的镜像服务器将它的数据库作为主体数据库，则没有在以前的镜像服务器上定义登录名的用户将无法访问新的主体服务器。用户将处于孤立状态。

如果用户在新的主体服务器上处于孤立状态，则需要在新主体服务器上创建登录名并运行 sp_change_users_login (Transact-SQL)。有关详细信息，请参阅孤立用户故障排除。

如果尝试连接到镜像数据库的应用程序正在使用 SQL 身份验证，则 SID 不匹配可能导致在故障转移后应用程序的登录名无法解析，使得该登录名成为孤立用户。可以使用 sp_change_users_login 解析孤立用户（请参阅孤立用户故障排除）。

但是，我们建议您在设置这样的应用程序来使用镜像数据库时采取预防性措施。有关如何避免发生此问题的信息，请参阅知识库文章 918992：如何在 SQL Server 2005 和 SQL Server 2008 实例间转移登录名和密码。

注意
使用 Windows 身份验证时不会出现此问题，因为 Windows 登录名的 SID 不是特定于计算机的，而是从 Active Directory 获取的。

作业（如备份作业）需要特殊考虑。通常，在角色切换后，数据库所有者或系统管理员必须为新主体数据库重新创建作业。

如果以前的主体服务器可用，还应该从新的镜像数据库中删除原始作业。镜像数据库上的作业失败，因为它处于正在还原状态，所以不可用。

注意
伙伴的配置可能不同，如具有不同的磁带机号等。每个伙伴的作业必须允许任何这类不同的配置。