SQL Server 2008 R2: problèmes après le changement de nom d'ordinateur

Je rencontre un problème déroutant après avoir changé le nom d'ordinateur d'un serveur distant hébergeant une instance SQL Server locale.

Fondamentalement, un serveur distant a été déplacé d'un site à un autre. Afin de faciliter cela, j'ai sauvegardé et restauré l'ancienne base de données sous un nouveau nom de base de données, effaçant les données afin qu'elles puissent être utilisées comme une nouvelle base de données pour le logiciel client. J'ai également changé le nom de l'ordinateur, comme nous le faisons toujours pour identifier chaque serveur par son numéro de site.

La base de données peut être connectée très bien par le logiciel client, et je peux me connecter directement à SQL Server très bien. Cependant, l'un de mes travaux de l'Agent SQL Server échoue, avec une erreur dans le journal des événements:

Travail planifié SQL Server 'Nightly Reset' (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Statut: échec - Appelé le: 2012-02-07 08:10:05 - Message: le travail a échoué. Impossible de déterminer si le propriétaire (Site-19 \ Admin) du travail Nightly Reset a accès au serveur (raison: impossible d'obtenir des informations sur le groupe / utilisateur Windows NT 'Site-19 \ Admin', code d'erreur 0x534. [SQLSTATE 42000] ( Erreur 15404)).

Maintenant, «Site-19» est l'ancien nom de l'ordinateur, qui a été modifié et le serveur a été réinitialisé. Je me connecte manuellement en utilisant «Site-28», le nouveau numéro de site, et il me montre que je suis connecté au serveur SQL avec Site-28 \ Admin. Cependant, lorsque je regarde les propriétés du travail de l'agent, il montre que le propriétaire est Site-19 \ Admin, et lorsque j'essaie de rechercher des utilisateurs pour le modifier, Site-28 \ Admin n'apparaît pas comme une option , uniquement Site-19 \ Admin. Si je crée un script pour un nouveau travail à partir de celui-ci et que je change manuellement le propriétaire en «Site-28 \ Admin», le nouveau travail est créé avec le propriétaire «Site-19 \ Admin».

En regardant dans sys.servers (ou via sp_helpserver), je n'ai qu'une seule entrée: le nom de l'ordinateur actuel. Cependant, SELECT @@ SERVERNAME renvoie le nom d'origine de la machine de développement (il y a deux changements de nom).

En bref, je ne peux pas exécuter ce travail important de l'Agent SQL Server car il appartient à un utilisateur qui n'existe plus et je ne peux pas comprendre comment le modifier ou le créer en tant qu'utilisateur correct.

Lorsque vous avez ajouté le nouveau nom de serveur à l'aide de sp_addserver, vous êtes-vous souvenu d'inclure la désignation "locale". C'est cette balise qui met à jour les métadonnées pour @@ SERVERNAME. Plus d'information.

sp_addserver 'servername', local

J'ai trouvé la réponse hier avec l'aide d'un de mes amis. J'ai dû me connecter via SSMS avec un utilisateur autre que la connexion Windows que j'essayais d'utiliser, supprimer l'ancienne connexion et ajouter à nouveau ma connexion Windows. Après cela, j'ai pu transférer correctement la propriété du travail, SQL a pu obtenir les données utilisateur de Windows, et tout allait bien avec le monde.

J'utilise les éléments suivants pour identifier les problèmes et créer la bonne instruction drop et add, si vous obtenez TOUT OK, vous n'avez rien à faire sinon vous devez exécuter les commandes.

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'

Eu un problème similaire: changé le nom d'hôte d'un ordinateur sur lequel SQL Server et SQL Server Agent sont en cours d'exécution. Des emplois ont été attribués à. Après avoir créé un utilisateur temporaire / connexion à SSMS à l'aide de ce nouvel utilisateur temporaire / suppression et créer le nom de connexion (publics et administrateurs système!) / Réaffecter les travaux à cette connexion recréée, tout allait bien. Vous pourriez peut-être manipuler une table système pour refléter le même changement; mais la méthode ci-dessus n'est pas si risquée.