☰

手动故障转移后用户映射丢失

tag-icon • tag-icon sql-server-2005 mirroring
手动故障转移后用户映射丢失

我设置了两个 Microsoft SQL Server 实例，每个实例都具有多个数据库，用于镜像。有多个登录名，每个数据库都有一个或多个用户/登录名映射。

当我恢复数据库备份时，我总是必须重新进行登录/用户映射。我理解这一点，因为登录是每个数据库服务器的。因此，在主服务器上恢复数据库后，我重新进行了登录/用户映射。这对于镜像服务器来说是不可能的，因为数据库正在“恢复”。

手动故障转移后，我无法使用数据库，因为缺少用户凭据。这并不意外，所以我再次进行了登录/用户映射。

我再次进行了手动故障转移，使初始主服务器（现在是镜像服务器）再次成为主服务器。令我惊讶的是，我无法使用数据库，因为登录名/用户映射消失了。

这是预期的行为吗？

答案1

这些是 SQL 登录名吗？如果是，那么主服务器和镜像服务器之间的 SQL 登录名和数据库用户之间的映射可能不同步。

我自己过去也遇到过这个问题，尽管我很幸运，只关心一个特定的用户。

您应该在镜子上尝试以下功能：

EXEC sp_change_users_login 'update_one', @login, @login

重置登录@login 和数据库用户@login 之间的映射。

如果这不起作用，请尝试“Auto_fix”方法：

EXEC sp_change_users_login 'Auto_Fix', @login, NULL, @password

如果数据库用户不存在，则这将创建数据库用户并进行相应的映射。

SQL 登录名会发生这种情况，因为数据库服务器将为这些登录名生成 SID。这些 SID 将数据库用户与登录名绑定在一起。即使同一登录名可能存在于两个不同的服务器上，它们的 SID 也可能不同，因此您可能会遇到“丢失”凭据的情况。Windows 帐户不会发生这种情况，因为 SQL Server 在创建关联登录名时将使用帐户本身的 Windows SID。

答案2

运行 sp_change_users_login 可以作为解决方法，但我喜欢通过以下步骤解决这个（常见）问题：

  1. 确定您遇到问题的 SQL Server 登录名。您应该能够忽略域登录名。最好忽略您的应用程序不使用的任何 SQL Server 登录名，最好的例子是“sa”。

  2. 选择一台将成为您“已知良好”系统的服务器。当前主服务器可能是最佳选择。

  3. 使用 sp_help_revlogin 对 TSQL 脚本进行逆向工程（从主脚本）以创建有问题的登录名。sp_help_revlogin 由 Microsoft 维护，网址为这一页。在辅助数据库中运行时，TSQL 脚本将保留 SQL Server 用于识别登录并将其链接到每个数据库中的用户的“SID”。

  4. 在辅助服务器上，删除有问题的登录名并运行您生成的 TSQL 脚本。重新创建登录名时，其 SID 将与主服务器的 SID 匹配。下次故障转移或将数据库从主服务器恢复到辅助服务器时，SID 应该匹配，您不必运行 sp_change_users_login 过程来“修复问题”。

在您熟悉此过程之前，最好一次登录一次。

请注意：运行该 TSQL 脚本还会将辅助服务器上的密码与主服务器上的密码同步。如果两台服务器上的密码不同（可能一台是开发服务器，一台是生产服务器），则可能必须返回将辅助服务器上的密码改回原密码。如果您不知道这些密码是什么，或者找不到人告诉您，这可能会成为一个问题。

  1. 在辅助服务器上运行脚本后，你应该仔细检查辅助服务器上所有数据库不是删除应用程序的一部分并修复其中的用户到登录名映射。例如，也许您在该系统上有 AdventureWorks。当您删除登录名时，用户到登录名映射将被破坏，必须重新创建。

答案3

在我的数据库上我通常使用这些命令：

EXEC sp_change_users_login 'Report'
EXEC sp_change_users_login 'Auto_Fix', 'username'
EXEC sp_change_users_login 'Report'

其中 username 是您要修复的用户名。

相关内容