У нас есть база данных с именем «foo» на первом экземпляре сервера sql с именем «SQL01», резервная копия которой создается каждую ночь с помощью моментального снимка с помощью Snap Manager для SQL Server, а затем гибко клонируется и восстанавливается на втором экземпляре сервера с именем «SQL02». В базе данных foo есть пользователь sql с именем someuser, у которого есть привилегии datareader и хранимой процедуры.
После операции восстановления я не могу получить доступ к базе данных foo на SQL02 с пользователем someuser. Я вижу, что разрешения установлены правильно для пользователя, но не может получить доступ к базе данных. Ошибка: «Основной сервер« someuser »не может получить доступ к базе данных« foo »в текущем контексте безопасности».
Если я удалю пользователя из базы данных, а затем добавлю его снова, он будет работать нормально. Любые идеи?
Чтобы избежать этой проблемы, добавьте своего пользователя (пользователя, выполняющего резервное копирование) в качестве пользователя базы данных резервного копирования, и ваш пользователь должен иметь доступ (вход в систему) в новом экземпляре.
Регистрационные данные сервера хранятся в базе данных master и не перемещаются вместе с базами данных приложений. Вы можете создать логин на уровне сервера, а затем использовать sp_change_users_login 'auto_fix', 'loginname', как было предложено Санкаром. Чтобы переместить больший набор логинов, перейдите по этой ссылке: Как передавать логины и пароли между экземплярами SQL Server
вы, вероятно, обнаружите, что вам нужно удалить пользователя из базы данных, которую вы восстановили, затем открыть пользователя в режиме безопасности сервера и снова установить его разрешения в этой базе данных
Проверять, выписываться sp_change_users_login Сделайте sp_change_users_login 'report', если есть результаты, используйте sp_change_users_login 'autofis', 'someuser'
sp_change_users_login - это старый способ работы, и, поскольку вы используете SQL Server 2005, попробуйте использовать синтаксис ALTER USER.
http://sqlblog.com/blogs/greg_low/archive/2009/02/02/much-ado-about-logins-and-sids.aspx