Назад | Перейти на главную страницу

SQL Server 2005 удаляет объекты из БД при восстановлении?

SQL Server 2005 удалил пользователя из одной из наших зеркальных баз данных после того, как мы восстановились после простого перезапуска компьютера, вызванного обновлением Windows.

Я проверил, и логина нет на зеркальном сервере (он есть на основном). Если в системе произошло аварийное переключение, объяснило бы это, почему пользователь был удален из пользовательской БД после восстановления на основной? Я не могу найти в документе ничего, что указывало бы на то, что SQL-сервер УБИРАЕТ осиротевших пользователей (http://msdn.microsoft.com/en-us/library/ms175475%28SQL.90%29.aspx). Что я должен искать в журналах?

Изменить: Настройка до сбоя: ПЕРВИЧНЫЙ - Войти в систему. Пользователь в базе данных в порядке. ЗЕРКАЛО - Логин не существует. Пользователь не существует в базе данных.

После сбоя: ПЕРВИЧНЫЙ - Авторизация ОК. Пользователь не существует в базе данных. ЗЕРКАЛО - Логин не существует. Пользователь не существует в базе данных.

РЕДАКТИРОВАТЬ: после восстановления системы БД после перезагрузки WINDOWS UPDATES на прошлой неделе мы заметили, что в одной из наших таблиц отсутствует триггер, как и другой пользователь. Я на 100% уверен, что это НЕ наша работа (у нас всего два са, и я один из них). ЧТО ЖЕ ТАКОЕ ПРОИСХОДИТ? Это должно быть ошибка зеркального отображения SQL Server 2005.

Создавался ли когда-либо логин на зеркальном сервере? В противном случае вам нужно будет записать логин из основной системы, чтобы SID совпадали.

Вот что, я думаю, произошло, это основано на догадке в вашем теге вопроса о orphaned-user, поэтому я могу ошибаться.

  1. ваша база данных переключилась с главного сервера на зеркало.
  2. сервер базы данных на зеркале (теперь основной) не имел сценария входа в систему с основного, а вместо этого был создан как новый вход. Это означало бы, что идентификаторы sid не совпадают, поэтому возникли проблемы с входом пользователя в систему после переключения.
  3. Чтобы исправить проблему входа в систему sp_change_users_login 'Update_One' был запущен, чтобы исправить проблему входа в систему. Это изменило бы sid пользователя в базе данных, чтобы он соответствовал sid входа на сервер базы данных.
  4. База данных снова терпит неудачу. Теперь sid входа на сервер базы данных больше не совпадает. Что делать? использовать sp_change_users_login еще раз, чтобы исправить проблему.

Что должно было случиться:
логины от принципала, которые используются в базе данных, которая участвует в зеркальном отображении, передаются по сценарию (как предложил мистер Денни) на зеркало. Самый простой способ сделать это - использовать sp_help_rev_login Вы также можете использовать Задача передачи логинов SSIS.

Sid для входа на сервер базы данных отображается в sys.server_principals. Sid для пользователей базы данных находится в sys.database_principals. Проверьте их, чтобы убедиться, что нет пропущенного совпадения.

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

Если вы добавите его позже, он будет перемещаться по зеркалу. Не логин, а CREATE USER будет перенесен.

Это было приложение нашего стороннего поставщика, которое отключило триггер как часть своего приложения. Безумие.

Спусковой крючок не сработал, потому что кто-то его уронил. Период. Без обид, но если вы являетесь одним из администраторов и не знаете, где находятся участники сервера и почему участники базы данных могут быть осиротевшими после аварийного переключения, то я не могу поверить, что вы знаете, почему триггер исчезает.

Использовать административный по умолчанию проследите, чтобы узнать, кто и когда уронил спусковой крючок. Если вам повезет, файл трассировки еще не был переработан. Установить на место аудит чтобы с этого момента отслеживать изменения, происходящие на вашем сервере. Для администраторов не должно быть «сюрпризом» исчезновение триггера. И нет, продукт нельзя винить.