SQL Server 2008 R2：计算机名称更改后出现问题

更改托管本地SQL Server实例的远程服务器的计算机名称后，我遇到一个令人困惑的问题。

基本上，远程服务器是从一个站点移动到另一个站点的。为了简化此操作，我备份了旧数据库并将其还原为新的数据库名称，清除了数据，以便可以将其用作客户端软件的新数据库。我还更改了计算机名称，因为我们总是这样做，以便通过服务器的站点号来标识每个服务器。

可以通过客户端软件很好地连接数据库，并且我可以直接登录到SQL Server。但是，我的一个SQL Server代理作业失败，事件日志中出现错误：

SQL Server计划的作业“立即重置”（0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD）-状态：失败-调用日期：2012-02-07 08:10:05-消息：作业失败。无法确定作业Nightly Reset的所有者（Site-19 \ Admin）的所有者（Site-19 \ Admin）是否具有服务器访问权限（原因：无法获取有关Windows NT组/用户'Site-19 \ Admin'的信息，错误代码0x534。[SQLSTATE 42000]（错误15404））。

现在，“ Site-19”是旧计算机名称，该名称已更改，并且服务器已重置。我使用新站点号'Site-28'手动连接，它显示我已通过Site-28 \ Admin连接到SQL Server。但是，当我查看代理作业的属性时，它显示所有者为Site-19 \ Admin，并且当我尝试浏览用户以对其进行更改时，Site-28 \ Admin不会显示为选项，只有Site-19 \ Admin。如果我从该脚本中编写了一个新作业，然后将所有者手动更改为“ Site-28 \ Admin”，则会使用所有者“ Site-19 \ Admin”创建新作业。

在sys.servers（或通过sp_helpserver）中查找，我只有一个条目：当前计算机名称。但是，SELECT @@ SERVERNAME返回原始的开发计算机名称（两个名称之前更改）。

简而言之，我无法运行此重要的SQL Server代理作业，因为该作业属于不再存在的用户，并且我不知道如何更改它或将其创建为正确的用户。

使用sp_addserver添加新服务器名称时，您是否记得要包含“本地”名称。正是该标签更新了@@ SERVERNAME的元数据。 更多信息。

sp_addserver 'servername', local

我昨天在我的一个朋友的帮助下找到了答案。我必须使用除我尝试使用的Windows登录名以外的用户通过SSMS登录，删除旧的登录名，然后再次添加Windows登录名。在那之后，我能够适当地转让工作的所有权，SQL能够从Windows获取用户数据，并且一切正常。

我使用以下命令来确定问题并构建正确的drop和add语句，如果一切正常，则无需执行任何操作，否则需要运行命令。

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后，拖放并创建登录名（public和sysadmin privs！）/将作业重新分配给此重新创建的Login，一切都很好。也许您可以操纵系统表以反映相同的更改；但是上面的方法没有那么大的风险。