У меня есть два экземпляра Microsoft SQL Server, настроенные для зеркального отображения, каждый с несколькими базами данных. Существует несколько учетных записей и для каждой базы данных одно или несколько сопоставлений пользователя / входа.
Когда я восстанавливаю резервную копию базы данных, мне всегда приходится переделывать сопоставления логина / пользователя. Я понимаю это, потому что логины для каждого сервера базы данных. Итак, после восстановления баз данных на предварительном сервере я переделал сопоставления логина / пользователя. Это было невозможно для зеркала, потому что базы данных «восстанавливались».
После ручной отработки отказа я не мог использовать базы данных, потому что учетные данные пользователя отсутствовали. Это не было неожиданностью, поэтому я снова выполнил сопоставление логина / пользователя.
Я снова выполнил ручное переключение, чтобы сделать первоначальный принцип, который теперь был зеркалом, снова основным. К моему удивлению, я не смог использовать базы данных, потому что сопоставления логина / пользователя пропали.
Это ожидаемое поведение?
Это логины 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 связывают пользователя базы данных с логином. Несмотря на то, что один и тот же логин может существовать на двух разных серверах, их идентификаторы безопасности могут быть разными, и, таким образом, вы можете потерять учетные данные, если захотите. Этого не происходит для учетных записей Windows, потому что SQL Server будет использовать идентификатор безопасности Windows для самой учетной записи при создании связанной учетной записи.
Выполнение процедуры sp_change_users_login - прекрасное решение, но мне нравится решать эту (общую) проблему с помощью следующих шагов:
Определите учетные записи SQL Server, с которыми у вас возникли проблемы. У вас должна быть возможность игнорировать вход в домен. Лучше всего игнорировать любые логины SQL Server, которые ваше приложение не использует, лучшим примером является «sa».
Выберите сервер, который будет вашей «заведомо хорошей» системой. Текущие первичные выборы, вероятно, лучший выбор.
Используйте процедуру sp_help_revlogin для обратного проектирования (с основного) сценария TSQL для создания проблемных входов. sp_help_revlogin поддерживается Microsoft по адресу эта страница. При запуске на вторичном сервере сценарий TSQL сохранит «SID», который SQL Server использует для идентификации логинов и связывания их с пользователями в каждой базе данных.
На вторичном сервере удалите проблемный вход в систему и запустите созданный вами сценарий TSQL. При воссоздании логина его SID будет соответствовать таковому у основного сервера. В следующий раз, когда вы переключитесь или восстановите базу данных с первичного на вторичный, SID должны совпадать, и вам не придется запускать процедуру sp_change_users_login для «исправления ситуации».
Пока вы не знакомы с этим процессом, лучше всего выполнять вход за раз.
Будьте осторожны: запуск этого сценария TSQL также синхронизирует пароль на вторичном сервере с паролем первичного. Если у вас разные пароли на двух серверах (возможно, один из них является сервером разработки, а другой - производственным), вам, возможно, придется вернуться и изменить пароль на вторичном сервере на тот, который должен быть. Если вы не знаете, что это за пароли, или не можете заставить кого-нибудь сообщить вам, это может быть проблемой.
На своих БД я обычно использую эти команды:
EXEC sp_change_users_login 'Report'
EXEC sp_change_users_login 'Auto_Fix', 'username'
EXEC sp_change_users_login 'Report'
где username - это имя пользователя, которое нужно исправить.