SQL Server 2008 R2: проблемы после изменения имени компьютера

У меня непонятная проблема после изменения имени компьютера удаленного сервера, на котором размещен локальный экземпляр SQL Server.

По сути, удаленный сервер был перемещен с одного сайта на другой. Чтобы облегчить это, я сделал резервную копию и восстановил старую базу данных с новым именем базы данных, очистив данные, чтобы их можно было использовать в качестве новой базы данных для клиентского программного обеспечения. Я также изменил имя компьютера, так как мы всегда делаем это, чтобы идентифицировать каждый сервер по номеру сайта.

База данных может быть подключена клиентским программным обеспечением просто отлично, и я могу войти прямо в SQL Server. Однако одно из моих заданий агента SQL Server завершается ошибкой с ошибкой в ​​журнале событий:

Запланированное задание SQL Server «Ночной сброс» (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Статус: Сбой - Вызван: 2012-02-07 08:10:05 - Сообщение: сбой задания. Невозможно определить, есть ли у владельца (Site-19 \ Admin) задания Nightly Reset доступ к серверу (причина: не удалось получить информацию о группе / пользователе Windows NT 'Site-19 \ Admin', код ошибки 0x534. [SQLSTATE 42000] ( Ошибка 15404)).

Теперь «Site-19» - это старое имя компьютера, которое было изменено, а сервер был перезагружен. Я подключаюсь вручную, используя «Site-28», новый номер сайта, и он показывает, что я подключен к SQL Server через Site-28 \ Admin. Однако, когда я смотрю на свойства задания агента, он показывает, что владельцем является Site-19 \ Admin, а когда я пытаюсь найти пользователей, чтобы изменить его, Site-28 \ Admin не отображается в качестве опции. Только Сайт-19 \ Админ. Если я создаю сценарий для нового задания из этого и вручную меняю владельца на «Site-28 \ Admin», то новое задание создается с владельцем «Site-19 \ Admin».

Глядя в sys.servers (или через sp_helpserver), у меня есть только одна запись: текущее имя компьютера. Однако SELECT @@ SERVERNAME возвращает исходное имя компьютера разработчика (два изменения названия назад).

Короче говоря, я не могу запустить это важное задание агента SQL Server, потому что оно принадлежит пользователю, которого больше нет, и я не могу понять, как его изменить или создать как правильного пользователя.

Когда вы добавили новое имя сервера с помощью sp_addserver, вы не забыли включить «локальное» обозначение. Именно этот тег обновляет метаданные для @@ SERVERNAME. Дополнительная информация.

sp_addserver 'servername', local

Я нашел ответ вчера с помощью моего друга. Мне пришлось войти через SSMS с пользователем, отличным от имени входа в Windows, которое я пытался использовать, удалить старый вход и снова добавить свой вход в Windows. После этого я смог правильно передать право собственности на задание, SQL смог получить пользовательские данные из Windows, и с миром все было в порядке.

Я использую следующее, чтобы определить проблемы и построить правильные операторы удаления и добавления. Если вы получите ОК, то вам не нужно ничего делать, в противном случае вам нужно будет запускать команды.

declare @currentName as nvarchar(128)
declare @newName as varchar(max)
declare @serverName as varchar(max)
declare @serverInstance as varchar(max)

select  @currentName = @@SERVERNAME
select @serverInstance = cast(serverproperty('InstanceName') as varchar(max))
select  @serverName = cast(serverproperty('MachineName') as varchar(max))

set @newName = @serverName

if (@serverInstance <> '') 
begin
      set @newName = @serverName + '\' + @serverInstance
end

if (@currentName <> @newName)
Begin
      print 'sp_dropserver ''' + @currentName + '''';
      print 'go'
      print 'sp_addserver ''' + @newName + ''',local'
      print 'go'
end
else
Print 'ALL OK'

Возникла похожая проблема: изменилось имя хоста компьютера, на котором запущены SQL Server и агент SQL Server. Рабочие места были назначены. После создания временного пользователя / входа в систему SSMS с использованием этого нового временного пользователя / drop и создания имени для входа (public и sysadmin privs!) / Переназначения заданий для этого воссозданного входа в систему все было в порядке. Возможно, вы могли бы манипулировать системной таблицей, чтобы отразить то же самое изменение; но выше метод не так рискован.