2009-03-20 5 views
0

J'ai un scénario étrange que je suis actuellement incapable d'expliquer. Je vis dans l'espoir que c'est juste "le sentiment du vendredi" ou qu'une seule gentille ici renflouera mon cerveau et me sauvera des boucles interminables de "mais pourquoi!?" :)SQL Server 2005 - Serveurs liés et travaux d'agent

Deux serveurs, exécutant SQL Server 2005, avec DNS Entrées de:

1. ServerA 
2. ServerB 

(Eh bien, ils ne sont pas vraiment appelés, mais il suffira ...)

sur Dans les deux instances SQL Server, des serveurs liés sont configurés en pointant vers l'autre serveur.

Pour des raisons évidentes de sécurité de la configuration de sécurité LinkedServer est réglé sur:

- Be made using the login's current security context 

Les autres « liés » Options du serveur sont ...

Collation Compatible: True 
Data Access:   True 
RPC:     True 
RPC Out:    True 
Use Remote Collation: True 
Collation Name:  <blank> 
Connection Timeout: 30 
Command Timeout:  10 

Une connexion est créée avec le même mot de passe les deux instances. Les connexions reçoivent les autorisations d'exécution appropriées pour les procédures stockées pertinentes.

j'écrire un code, et exécuter sous cette connexion et tout fonctionne hoorah


Mais quand je crée un Job Agent pour exécuter ces procédures stockées tout va mal. Le propriétaire de mon journalisation d'erreur Job Agent est « automated_job_login », mais donne les éléments suivants: - Échec de la connexion pour l'utilisateur « automated_job_login »

(Encore une fois ce nom a été modifié pour protéger les coupables.)


Je ne peux pas comprendre pour la vie de moi pourquoi cela fonctionnera quand je me connecte en tant que cet utilisateur, mais les erreurs de travail lors de la connexion au serveur lié. Pour rendre les choses plus confuses, si je change la configuration de la sécurité du serveur lié en «Soyez fait en utilisant ce contexte secuirty:» et spécifiez «automation_job_login» avec le mot de passe correct. , ça fonctionne bien.

Il me manque quelque chose, je sais que je dois être, mais je ne peux pas trouver quoi. J'ai lu de la documentation jusqu'à ce que mes yeux saignent et j'ai échoué. S'il vous plaît aidez-moi :)


[Laisser l'option Secuiry serveur lié comme « être faites en utilisant ce contexte secuirty: » est pas une option car cela donnerait à tous les utilisateurs de ce serveur niveaux unnaceptable d'accès à l'autre serveur. ]

Répondre

3

Le travail de l'agent SQL peut être la propriété de votre connexion, mais il n'est pas exécuté dans ce contexte de connexion. Parce que vous avez SQL Server 2005, vous pouvez utiliser EXEC AS USER = 'mylogin' comme une option proc stockée.

Sinon, vous devez définir le nom d'utilisateur de la base de données à l'aide du paramètre @database_user_name de sp_add_jobstep. In SSMS, vous pouvez définir le contexte. La propriété d'emploi est légèrement différente de la mise en place, IIRC.

+0

Merci pour l'aide, avez déjà regardé autour de cela. Fondamentalement, même si ma connexion est dans le groupe sysadmin je ne peux toujours pas changer l'option "Exécuter en tant que" dans le travail de l'agent ... – MatBailie

+0

peut-être alors au niveau de sp_add_jobstep? Désolé, mais je n'ai pas accès pour vérifier exactement dans ma boutique. Cependant, pouvez-vous changer des morceaux du travail? – gbn

+0

J'ai trouvé un article qui montrait qu'il y avait DEUX endroits pour définir "Exécuter en tant que" et que seul le second est utilisable pour les tâches T-SQL. Malheureusement, je reçois toujours l'erreur de connexion échouée * va croiser les yeux *. http://tinyurl.com/cyaeyw – MatBailie