SQL Server 2008 R2: problemas después del cambio de nombre de la computadora

Tengo un problema confuso después de cambiar el nombre de la computadora de un servidor remoto que aloja una instancia local de SQL Server.

Básicamente, un servidor remoto se movió de un sitio a otro. Para facilitar esto, hice una copia de seguridad y restauré la base de datos anterior a un nuevo nombre de base de datos, borrando los datos para que pudieran usarse como una nueva base de datos para el software del cliente. También cambié el nombre de la computadora, ya que siempre lo hacemos para identificar cada servidor por su número de sitio.

El software del cliente puede conectar a la base de datos perfectamente, y puedo iniciar sesión directamente en SQL Server. Sin embargo, uno de mis trabajos del Agente SQL Server falla, con un error en el registro de eventos:

Trabajo programado de SQL Server 'Restablecimiento nocturno' (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Estado: Fallido - Invocado el: 2012-02-07 08:10:05 - Mensaje: El trabajo falló. No se puede determinar si el propietario (Site-19 \ Admin) del trabajo Nightly Reset tiene acceso al servidor (razón: no se pudo obtener información sobre el grupo / usuario de Windows NT 'Site-19 \ Admin', código de error 0x534. [SQLSTATE 42000] ( Error 15404)).

Ahora, 'Sitio-19' es el antiguo nombre de la computadora, que se ha cambiado y el servidor se ha reiniciado. Me conecto manualmente usando 'Site-28', el nuevo número de sitio, y me muestra como conectado al SQL Server con Site-28 \ Admin. Sin embargo, cuando miro las propiedades del trabajo del Agente, muestra al propietario como Site-19 \ Admin, y cuando intento buscar usuarios para cambiarlo, Site-28 \ Admin no aparece como una opción , solo Site-19 \ Admin. Si escribo un nuevo trabajo desde este y cambio manualmente el propietario a 'Site-28 \ Admin', el nuevo trabajo se crea con el propietario 'Site-19 \ Admin'.

Al buscar en sys.servers (o mediante sp_helpserver), solo tengo una entrada: el nombre actual de la computadora. Sin embargo, SELECT @@ SERVERNAME devuelve el nombre original de la máquina de desarrollo (hace dos cambios de nombre).

En resumen, no puedo ejecutar este importante trabajo del Agente SQL Server porque pertenece a un usuario que ya no existe, y no puedo entender cómo cambiarlo o crearlo como el usuario correcto.

Cuando agregó el nuevo nombre del servidor utilizando sp_addserver, ¿recordó incluir la designación "local". Es esa etiqueta la que actualiza los metadatos para @@ SERVERNAME. Más información.

sp_addserver 'servername', local

Ayer encontré la respuesta con la ayuda de un amigo mío. Tuve que iniciar sesión a través de SSMS con un usuario que no sea el inicio de sesión de Windows que estaba intentando usar, eliminar el inicio de sesión anterior y agregar mi inicio de sesión de Windows nuevamente. Después de eso, pude transferir la propiedad del trabajo correctamente, SQL pudo obtener los datos de usuario de Windows, y todo estuvo bien con el mundo.

Utilizo lo siguiente para identificar problemas y crear las instrucciones correctas para soltar y agregar, si todo está bien, entonces no necesita hacer nada; de lo contrario, debe ejecutar los comandos.

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'

Tuve un problema similar: cambió el nombre de host de una computadora donde se ejecuta SQL Server y el Agente SQL Server. Se asignaron trabajos a. Después de crear un usuario temporal / iniciar sesión en SSMS usando este nuevo usuario temporal / soltar y crear el nombre de inicio de sesión (¡public y sysadmin privs!) / Reasignar los trabajos a este inicio de sesión recreado, todo estuvo bien. Tal vez podría manipular una tabla del sistema para reflejar el mismo cambio; pero el método anterior no es tan arriesgado.