3

场景：

尝试从从 SQL Azure 获取的 bacpac 进行恢复。

到新的 SQL Azure 数据库实例或本地服务器。对于较早的使用管理门户或DAC 框架客户端工具。

它似乎工作正常，并且在还原后自然不会将 SQL 用户映射到 SQL 登录名。

我尝试了什么：

当我尝试将其映射为: alter user MyUser with login = MyLogin时，它失败了：

消息 33016，级别 16，状态 1，第 6 行 用户无法重新映射到登录。只能对映射到 Windows 或 SQL 登录的用户进行重新映射。

Runningselect * from sys.database_principals确实列出了用户，但 SID 比我创建的用于比较它的 SQL 身份验证用户长得多。

如果我在本地运行，sp_change_users_login 'Report'则用户未列出，因此不会被检测为孤立的。

如果我尝试使用sp_change_users_login在本地，它会失败并显示：

消息 15291，级别 16，状态 1，过程 sp_change_users_login，第 114 行终止此过程。用户名“MyUser”不存在或无效。

在本地，如果我通过登录属性 UI 的用户映射部分进行尝试，我会得到：

为用户“我的用户”创建失败。... 用户、组或角色“MyUser”已存在于当前数据库中。

我试着重新做一遍，以防在恢复时由于某种原因损坏了，结果相同。

问题：

如何重新映射这些 SQL 用户？

我想避免必须从头开始重新创建它们以及它们与数据库中的模式对象的任何关系？

一些额外的信息：

一种看起来很像我看到的 SQL Azure 用户的 SQL 用户，是用

create user AnotherUser without login

在我上面使用的所有 3 种映射方法中，这些方法都以完全相同的方式失败。常规 SQL 用户的任何方法都不是这种情况。此外，sid 也很长，以相同的“0x010500000000000903000000”开头

4

3 回答 3

1

一篇sqlmatters 文章解释说

没有登录的用户是一种特殊类型的用户，故意设置为没有关联的登录。

可以通过检查 SID 来检查是否属于这种情况：

 -- SQL to run to identify users without login :
SELECT CASE WHEN DATALENGTH(sid) = 28
             AND type = 'S'       -- only want SQL users
             AND principal_id > 4 -- ignore built in users
     THEN 1 ELSE 0 END AS is_user_without_login,*
FROM sys.database_principals

没有登录的用户的 SID 比普通（孤立）用户长。

这些特殊用户无法映射到登录名，因为他们是那样制作的。一定有人故意或错误地创建了一个用户WITHOUT LOGIN。

于 2018-07-20T12:47:39.293 回答
0

如果你得到那个，它很可能是一个损坏的备份。就像链接的本地场景一样，该行为无处不在，并被追踪到损坏的备份。

在我的情况下，它是一样的。在发布问题之前，我最后一次尝试是：数据库的不同备份，它没有问题。

于 2012-01-02T21:53:53.490 回答
0

您还可以使用以下内容找到可以映射到登录名的用户：

SELECT *
FROM sys.database_principals
WHERE 1=1
    AND [type] = 'S'
    AND [name] NOT IN ('dbo','guest','INFORMATION_SCHEMA','sys')
    AND authentication_type_desc IN ('WINDOWS','INSTANCE')
于 2019-10-13T22:06:03.783 回答