INF : Comment faire pour exécuter un lot DTS en tant que tâche planifiée

Traductions disponibles Traductions disponibles
Numéro d'article: 269074 - Voir les produits auxquels s'applique cet article
Cet article peut contenir des liens vers des informations en langue anglaise (pas encore traduites).
Agrandir tout | Réduire tout

Sommaire

Résumé

Un problème que vous pouvez rencontrer fréquemment avec un lot DTS (Data Transformation Services) est que celui-ci s'exécute sans erreur à partir de SQL Server Enterprise Manager, mais qu'il échoue lorsqu'il est planifié pour s'exécuter en tant que tâche. Habituellement, cela se produit à cause d'une différence dans le contexte de sécurité lorsque le lot est exécuté en tant que tâche contrairement à lorsqu'il est exécuté interactivement.

Cet article explique les problèmes de sécurité impliqués dans l'exécution de lots DTS.

Plus d'informations

Cet article contient les termes suivants :
Réduire ce tableauAgrandir ce tableau
TermesDescription
DTSData Transformation Services
Authentification SQLUn système de sécurité basé sur les noms d'accès et les mots de passe Microsoft SQL Server.
Sécurité standardVoir authentification SQL
Authentification SQL ServerVoir authentification SQL
Authentification Microsoft Windows NTLorsqu'un utilisateur se connecte à l'aide d'un compte d'utilisateur Microsoft Windows, SQL Server vérifie que le nom de compte et le mot de passe ont été validés lorsque l'utilisateur a ouvert une session sur un ordinateur Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows 95 ou Microsoft Windows 98.
Sécurité intégréeVoir authentification Microsoft Windows NT
Authentification Windows NT ou Microsoft Windows 2000Voir authentification Microsoft Windows NT
Le compte ou le nom d'accès Microsoft Windows NT correspond au nom d'accès ou au compte WindowsMême chose pour le compte d'ouverture de session Microsoft Windows NT ou le compte d'ouverture de session Microsoft Windows 2000.
Agent SQLService de l'Agent SQL Server
SEMSQL Server Enterprise Manager

Où le lot DTS s'exécute-t-il ?

Un problème qui est fréquemment rapporté à propos des lots DTS est la différence de comportement lorsqu'un lot s'exécute à partir de SQL Enterprise Manager et lorsqu'il est planifié en tant que tâche. Lorsque vous exécutez le lot à partir du Concepteur DTS de SQL Enterprise Manager (SEM), le lot s'exécute sur l'ordinateur devant lequel vous êtes assis. Si vous êtes au niveau du serveur (que ce soit physiquement ou à travers un logiciel d'accès distant), le lot s'exécute sur le serveur. Si vous êtes assis devant une station de travail et vous avez enregistré le serveur SQL Server dans Enterprise Manager, alors le lot s'exécute sur la station de travail. Le contexte de sécurité du lot est celui du compte Windows NT que vous avez utilisé pour ouvrir une session sur cet ordinateur. Lorsque le lot s'exécute en tant que tâche planifiée, il s'exécute toujours sur le serveur.

Fréquemment, un développeur crée et teste interactivement le lot DTS sur sa station de travail à travers le Concepteur DTS dans Enterprise Manager. Une fois que le lot DTS est débogué, il est ensuite planifié en tant que tâche. Cela modifie l'emplacement du lot de la station de travail du développeur vers le serveur. Si le lot était en train de charger des données textuelles dans SQL Server, il échoue, à moins que le fichier textuel et le chemin d'accès au fichier n'existent sur le serveur. Si le lot était en train de se connecter à un autre serveur, il échoue si le contexte de sécurité de la tâche ne prend pas en charge la connexion.

Qui est propriétaire de la tâche que le lot DTS exécute ?

Les lots sont planifiés en créant une tâche gérée par le service d'Agent SQL. Cette tâche, comme toute autre tâche planifiée, a un propriétaire. Le propriétaire peut être soit un nom d'accès SQL Server, soit un compte Windows NT.

Pour déterminer le propriétaire, procédez comme suit :
  • Double-cliquez sur la tâche dans Enterprise Manager, puis regardez la zone de liste déroulante modifiable Propriétaire.

    - ou -

  • Exécutez la procédure stockée système msdb.dbo.sp_help_job.
SQL Server 7.0

Le contexte de sécurité dans lequel la tâche s'exécute est déterminé par le propriétaire de la tâche. Si le propriétaire de la tâche est un nom d'accès qui n'est pas membre du rôle de serveur Sysadmin, alors le lot est exécuté sous le contexte du compte SQLAgentCmdExec et dispose des droits et autorisations de ce compte.

Pour que SQLAgentCmdExec puisse exécuter les tâches qui se connectent à SQL Server, le compte SQLAgentCmdExec doit disposer des autorisations Windows/NT adéquates et bénéficier d'un accès de connexion à SQL Server avec les autorisations de base de données adéquates. Le compte SQLAgentCmdExec n'a généralement pas de droit en dehors de l'ordinateur SQL Server local. Par conséquent, tout lot qui requiert une connexion à un autre ordinateur échoue, s'il est planifié en tant que tâche dont le propriétaire est un nom d'accès qui n'est pas membre du rôle Sysadmin.

SQL Server 2000

Le contexte de sécurité dans lequel la tâche s'exécute est déterminé par le propriétaire de la tâche. Si le propriétaire de la tâche est un nom d'accès qui n'est pas membre du rôle de serveur Sysadmin, alors le lot est exécuté sous le contexte du compte configuré comme le compte proxy de l'Agent SQL et dispose des droits et autorisations de ce compte.

Pour que SQL Agent Proxy puisse exécuter les tâches qui se connectent à SQL Server, le compte proxy de l'Agent SQL doit disposer des autorisations Windows/NT adéquates et bénéficier d'un accès de connexion à SQL Server avec les autorisations de base de données adéquates. Pour les tâches qui exécutent un lot DTS, le compte proxy de l'Agent SQL doit avoir lu et écrit les autorisations vers le répertoire temporaire du compte sous lequel l'Agent SQL Server s'exécute. Par exemple,
c:\Documents and Settings\<Compte>\Local Settings\Temp
Si le propriétaire de la tâche est un compte (un nom d'accès SQL Server ou un nom d'accès authentifié Windows NT) qui est membre du rôle Sysadmin, la tâche de l'Agent SQL s'exécute sous le contexte du compte utilisé pour démarrer le service de l'Agent SQL.

De même, si le propriétaire de la tâche est un compte de domaine Windows NT et si le lot est stocké dans SQL Server ou dans le référentiel SQL Server (pas en tant que fichier), vous devez démarrer le service SQL Server en utilisant un compte du même domaine ou un compte d'un domaine approuvé. Par exemple, si le propriétaire de la tâche de l'Agent SQL est un compte du domaine USA, alors le compte utilisé pour démarrer le service SQL Server doit être soit du domaine USA, soit d'un domaine approuvé par le domaine USA. Si SQL Server est démarré à l'aide d'un compte local, le lot ne parvient pas à s'exécuter.

Qu'est-ce qui détermine le propriétaire ?

Question : Lorsque vous cliquez avec le bouton droit sur le lot DTS et choisissez de planifier le lot, comment le propriétaire est-il attribué ?

Réponse : Le propriétaire de la tâche de l'Agent SQL dépend de la façon dont SQL Server est enregistré dans Enterprise Manager. Si SQL Server est enregistré à l'aide d'une authentification Windows NT, le propriétaire de la tâche planifiée est le compte utilisé pour démarrer le service de l'Agent SQL. Si SQL Server est enregistré dans SEM à l'aide de l'authentification SQL Server (par exemple, le nom d'accès SA), le propriétaire de la tâche est ce même nom d'accès SQL Server.

Pour modifier la propriété du lot, procédez comme suit :
  1. Double-cliquez sur la tâche dans Enterprise Manager.
  2. Cliquez sur l'onglet Général, puis sur la zone de liste déroulante modifiable Propriétaire.
Vous pouvez également utiliser la procédure stockée système msdb.dbo.sp_update_job pour modifier la propriété du lot.

Comment le lot DTS est-il lancé ?

Si vous exécutez manuellement un lot en utilisant l'utilitaire de ligne de commande DTSRun.exe, le contexte de sécurité est celui du compte Windows que vous avez utilisé pour ouvrir une session sur l'ordinateur. Si vous exécutez le lot en utilisant DTSrun.exe à travers la procédure stockée étendue xp_cmdshell, le lot est exécuté dans le contexte du compte utilisé pour démarrer le service SQL Server, à condition que l'utilisateur qui a exécuté xp_cmdshell soit membre du rôle Sysadmin. Si l'utilisateur qui a exécuté xp_cmdshell n'est pas un compte du rôle Sysadmin, alors DTSRun.exe s'exécute dans le contexte du compte SQLAgentCmdExec.

Si SQL Server a été démarré à l'aide du compte système local, le lot DTS n'a pas d'autorisation en dehors de l'ordinateur qui exécute SQL Server.

Si le service SQL Server est démarré sous un compte Windows NT, le lot dispose des mêmes droits et autorisations que ce compte Windows NT. Si ce compte Windows NT est un compte d'ordinateur local (par opposition à un compte de domaine), le lot ne dispose pas de droit en dehors de cet ordinateur. Si le compte Windows NT est un compte de domaine, le lot peut être capable d'accéder aux ressources sur d'autres ordinateurs de ce domaine.

Comment les connexions authentifiées Windows NT sont-elles établies ?

Parfois, un lot DTS contient un objet qui établit une connexion à une source de données à l'aide de l'authentification Windows NT. Le contexte de sécurité utilisé pour cette connexion est le même que le contexte du lot qui s'exécute. Si le lot est exécuté à partir d'une invite de commandes à l'aide de DTSRun.exe, les informations d'identification du compte Windows NT actuellement connecté sont utilisées. Si le lot est exécuté en tant que tâche de l'Agent SQL Server, alors la connexion de sécurité intégrée est établie à l'aide du compte que vous avez utilisé pour démarrer l'Agent SQL (en supposant que le propriétaire du lot soit membre du rôle Sysadmin).

Problèmes courants

Voici quelques problèmes courants supplémentaires que vous pouvez rencontrer lorsque vous exécutez des lots DTS en tant que tâches planifiées dans l'Agent SQL :

Lecteurs mappés

Si le lot repose sur l'emplacement physique d'un fichier désigné par une lettre de lecteur mappé, il peut échouer lorsqu'il est exécuté en tant que tâche planifiée de l'Agent SQL, quel que soit son propriétaire. L'Agent SQL est un service Windows NT et les services Windows NT ne peuvent pas voir les lettres de lecteurs mappées. Le mappage fait partie du profil de l'utilisateur qui est chargé lorsqu'un utilisateur ouvre une session Windows NT. Les services ne fonctionnent pas avec les profils d'utilisateurs. Utilisez un chemin UNC au lieu d'une lettre de lecteur mappé. Pour plus d'informations sur la raison pour laquelle un service ne peut pas utiliser de lecteur mappé, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
180362 INFO : Services et lecteurs redirigés

Chemin d'accès relatif

Un chemin d'accès relatif (ou lettre de lecteur) est spécifique à l'emplacement actuel du lot (comme C:\). Si un lot est conçu sur une station de travail et qu'il est ensuite planifié, l'emplacement à partir duquel il est exécuté est modifié. Les chemins d'accès de lettre de lecteur référencent désormais un emplacement physique différent, celui du serveur. À moins que les fichiers référencés ne soient également déplacés vers le serveur, l'exécution du lot échoue.

Composants COM dans des scripts ActiveX

Si des composants COM (par exemple, appels à des objets Microsoft ADO (ActiveX Data Objects), RDO (Remote Data Objects) ou DSO (Decision Support Object)) sont appelés dans un script ActiveX, les composants appelés doivent exister sur l'ordinateur à partir duquel le lot DTS est exécuté. Si vous exécutez le lot à partir du concepteur DTS de SEM ou DTSRun.exe, les composants doivent exister sur l'ordinateur devant lequel vous êtes assis. Si le lot est planifié pour être exécuté par l'Agent SQL, les composants appelés doivent être chargés sur l'ordinateur qui héberge SQL Server.

Sécurité de lot

Les lots DTS peuvent avoir des mots de passe de propriétaire et des mots de passe d'utilisateur. Ces mots de passe contrôlent qui peut modifier et exécuter les lots. Ils n'affectent pas le contexte de sécurité dans lequel le lot est exécuté.

Autorisations SQLAgentCmdExec

Si la tâche est exécutée sous le contexte du compte SQLAgentCmdExec et que le compte SQLAgentCmdExec ne dispose pas de droit d'ouverture de session sur SQL Server, la tâche peut échouer et afficher le message d'erreur suivant :
DTSRun : en chargement... DTSRun : en exécution... DTSRun en démarrage : DTSStep_DTSExecuteSQLTask_1 DTSRun OnError : DTSStep_DTSExecuteSQLTask_1, Erreur = -2147217843 (80040E4D) Chaîne de l'erreur : Échec de la connexion de l'utilisateur 'Nom_NT\SQLAgentCmdExec'. Source de l'erreur : Fournisseur Microsoft OLE DB pour fichier d'aide SQL Server : Contexte d'aide : 0 Enregistrements des détails de l'erreur : Erreur : -2147217843 (80040E4D); Erreur de fournisseur : 18456 (4818) Chaîne de l'erreur : Échec de la connexion de l'utilisateur 'Nom_NT\SQLAgentCmdExec'. Source de l'erreur : Fournisseur Microsoft OLE DB pour fichier d'aide SQL Server : Contexte d'aide : 0 DTSRun en voie d'achèvement : DTSStep_DTSExecuteSQLTask_1 DTSRun : exécution du lot terminée. Code de fin de processus 1. L'étape a échoué.
Vous devez accorder au compte SQLAgentCmdExec des droits adéquats d'ouverture de session et d'autorisation d'accès à la base de données sur SQL Server.

Propriétés

Numéro d'article: 269074 - Dernière mise à jour: mardi 10 mai 2011 - Version: 5.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 7.0 Standard
  • Microsoft SQL Server 2000 Standard
Mots-clés : 
kbsqlserverengine kbproductlink kbinfo KB269074
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com