Исправить для бесхозного пользователя 'гость'?

Что можно сделать, если что-нибудь, когда специальный guestпользователь осиротел (не связан ни с каким логином)?

Для одной из моих баз данных (SQL Server 2005) при выполнении следующего перечисляется гостевой пользователь как потерянный пользователь.

exec sp_change_users_login 'report'

Результаты:

UserName    UserSID
guest       0x3C2E66759FFBC14F84127D6795C27FD3

Если я пытаюсь исправить гостевого пользователя с помощью этой процедуры, я получаю следующее:

exec sp_change_users_login 'update_one', 'guest', 'guest'

Прекращение этой процедуры. 'guest' - это запрещенное значение для параметра имени входа в этой процедуре.

Если я пытаюсь удалить пользователя, я получаю:

Пользователь 'guest' не может быть удален, его можно только отключить.

select * from sys.database_principals where name = 'guest'

Результаты в:

name                 guest
principal_id         2
type                 S
type_desc            SQL_USER
default_schema_name  guest
create_date          11/13/98 2:58 AM
modify_date          10/16/01 4:31 PM
owning_principal_id  NULL
sid                  0x3C2E66759FFBC14F84127D6795C27FD3
is_fixed_role        0

База данных, похоже, не понимает, является ли это специальный пользователь или нет. Есть ли что-нибудь, что можно сделать?

Пользователь «гость» никогда не назначается для входа на сервер, даже при новой установке он классифицируется как пользователь SQL без имени входа. Поскольку вы можете установить только SID логина (при создании), а не пользователя, я не верю, что это возможно; Процедура sp_change_users_login не работает точно по той причине, что учетная запись гостя никогда не должна быть сопоставлена ​​с именем входа на сервер. В результате пользователь «гость» всегда является осиротевшим пользователем. Вероятно, не тот ответ, который вы хотели, хотя :)

Мои мысли ... Причина кроется sp_change_users_loginв том, что MS тоже это написала. [Просматривать код системной процедуры время от времени может быть весело. :)] Однако тот факт, что он появляется при запуске отчета, указывает на то, что кто-то / какой-то процесс испортил учетную запись, или возможное оперативное исправление от MS могло бы сделать это (вы никогда не знаете).

Предполагается, что гостевая учетная запись существует, она существует в каждой создаваемой базе данных, поскольку учетная запись существует в модели по умолчанию. 0x00Я полагаю, что для того, чтобы он не отображался в отчете, потребовалось бы вернуть SID обратно . Пока учетная запись отключена, я оставляю ее в покое и игнорирую ее. Если бы это действительно беспокоило меня, я бы раскошелился на деньги и позвонил бы в службу поддержки Microsoft.

Примечание. Каждый раз, когда вы перемещаете базу данных с одного сервера на другой, обычно возникает проблема, связанная с отсутствием пользователя. FileListOnly - это новый термин в SQL Server, который содержит все детали созданной резервной копии, которая имеет к ней доступ.

Таким образом, есть последовательность задач, которым вы должны следовать

1. Сначала необходимо восстановить FileListOnly из созданной резервной копии на целевой или новый сервер.
2. Восстановите резервную копию.
3. Используйте sp_change_users_login согласно необходимости. Для получения справки об этой процедуре вы можете обратиться по адресу http://msdn.microsoft.com/en-us/library/ms174378.aspx .

Я положил пример здесь, надеюсь, что это поможет:

> RESTORE FILELISTONLY FROM DISK = N'C:\YourDB.bak'
> 
> RESTORE DATABASE YourDb FROM DISK = N'C:\YourDB.bak' WITH MOVE
> N'YourDB' TO N'D:\YourDB.mdf', MOVE N'YourDB_log' TO N'D:\YourDB.ldf',
> REPLACE
> 
> exec YourDB.dbo.sp_change_users_login 'update_one', 'UserName','UserName'