Résolution des problèmes : exécution du package SSIS à l'aide de l'Agent SQL Server (vidéo de SQL Server)
S'applique à : Microsoft SQL Server Integration Services |
Auteur : Carla Sabotta, Microsoft Corporation |
Durée : 12 min 12 s Taille : 9,5 Mo Type : fichier WMV |
Résumé de la vidéo
Cette vidéo montre comment résoudre les problèmes liés à un package SQL Server Integration Services qui n'est pas exécuté lorsque vous l'appelez à partir d'une étape de travail de l'Agent SQL Server. Le package est correctement exécuté hors de l'Agent SQL Server.
Transcription de la vidéo
| Horodateur de la vidéo | Audio |
|---|---|
00:00 |
Bonjour. Je m'appelle Carla Sabotta et je rédige la documentation du produit Microsoft SQL Server Integration Services. Dans cette vidéo, je vais vous montrer comment résoudre les problèmes liés à un package SQL Server Integration Services qui n'est pas exécuté lorsque vous l'appelez à partir d'une étape de travail de l'Agent SQL Server. Le package est correctement exécuté hors de l'Agent SQL Server. Vous étudierez les méthodes recommandées pour la résolution de ce problème, notamment la création d'un compte proxy, la modification du paramètre de propriété ProtectionLevel du package, l'enregistrement de données sensibles dans un fichier de configuration de package et le stockage d'un package dans la base de données SQL Server msdb. Comme vous pouvez le voir, ce travail n'a pas réussi à exécuter le package Integration Services. Lorsque vous appelez un package à partir d'une étape de travail de l'Agent SQL Server et que le package n'est pas exécuté, l'une des conditions suivantes est remplie :
Lorsque le compte d'utilisateur qui appelle le package à partir de l'étape de travail est différent de l'auteur du package d'origine, le niveau de protection du package peut empêcher son exécution. Cela est dû au fait que le compte d'utilisateur ne peut pas déchiffrer le package ou ses données sensibles, ou que le compte d'utilisateur ne peut pas fournir les données sensibles qui manquent dans le package. Des exemples de données sensibles sont la partie mot de passe d'une chaîne de connexion, une variable marquée comme sensible, etc. Plusieurs méthodes recommandées permettent de résoudre les problèmes liés au chiffrement et aux données sensibles. |
01:53 |
La première méthode consiste à stocker le package dans la base de données SQL Server msdb et à affecter au niveau de protection la valeur Se fier au stockage et aux rôles du serveur pour le contrôle d'accès (Rely on server storage and roles for access control). Pour ce faire, utilisez le service Integration Services de SQL Server Management Studio. Les rôles de base de données contrôlent à présent les accès en lecture et en écriture au package. Vous devez attribuer l'un des rôles de niveau base de données fixes Integration Services ou un rôle de niveau base de données défini par l'utilisateur au rôle de lecteur du package. Les rôles de niveau base de données fixes sont db_ssisadmin, db_ssisoperator et db_ssisltduser. Dans cette démonstration, nous attribuerons le rôle db_ssisadmin au package. Si vous attribuez un rôle de niveau base de données fixe au package, le compte d'utilisateur qui appelle le package à partir de l'étape de travail doit être membre de ce rôle. Si vous attribuez un rôle défini par l'utilisateur au package, le compte d'utilisateur doit être membre de l'un des rôles de niveau base de données fixes et du rôle défini par l'utilisateur. |
03:59 |
La deuxième méthode consiste à remplacer le paramètre de propriété ProtectionLevel du package par EncryptSensitiveWithPassword, dans Business Intelligence Development Studio. Vous accédez à la propriété ProtectionLevel du package en cliquant n'importe où dans le flux de contrôle du package, puis en sélectionnant ProtectionLevel dans la fenêtre Propriétés. Vous modifiez ensuite la ligne de commande de l'étape de travail de l'Agent SQL Server pour inclure le mot de passe qui déchiffre les données sensibles. Vous ajoutez le mot de passe à l'aide du paramètre /Decrypt de l'utilitaire d'invite de commandes dtexec. Les étapes de travail de l'Agent SQL Server emploient l'utilitaire dtexec pour exécuter des packages. |
05:22 |
La troisième méthode permettant de résoudre les problèmes liés au chiffrement et aux données sensibles consiste à remplacer le paramètre de propriété ProtectionLevel du package par DontSaveSensitive, à nouveau en utilisant Business Intelligence Development Studio. Avec ce paramètre de propriété, le package n'est pas chiffré et les données sensibles ne sont pas enregistrées avec le package. Par conséquent, vous utilisez un fichier de configuration de package pour enregistrer les données. Dans cette démonstration, nous enregistrerons la partie mot de passe d'une chaîne de connexion pour le gestionnaire de connexions DestinationConnectionOLEDB. Lorsque l'étape de travail de l'Agent SQL Server exécute le package, les données sensibles sont chargées à partir du fichier de configuration créé. Assurez-vous de stocker le fichier dans un dossier sécurisé. Jusqu'à présent, nous avons examiné les méthodes permettant de résoudre les problèmes liés au chiffrement et aux données sensibles. L'autre condition qui entraîne l'échec de l'exécution d'un package par une étape de travail de l'Agent concerne les autorisations du compte d'utilisateur. Le compte d'utilisateur n'a pas les autorisations requises pour établir des connexions ou accéder aux ressources hors du package. |
08:08 |
Pour tester les autorisations du compte d'utilisateur, ouvrez une fenêtre d'invite de commandes et exécutez la commande RunAs. Remplacez mondomaine\monutilisateur par les informations d'authentification stockées dans les informations d'identification du compte. Lorsque vous y êtes invité, tapez le mot de passe du compte. La méthode recommandée pour résoudre le problème des autorisations consiste à créer un compte proxy de l'Agent SQL Server qui dispose des autorisations requises. Le compte proxy déchiffre également les données sensibles dans le package. Gardez à l'esprit que cette méthode peut échouer si vous déplacez le package vers un autre ordinateur et que la propriété ProtectionLevel du package a la valeur EncryptSensitiveWithUserKey ou EncryptAllWithUserKey. |
09:12 |
Pour créer un compte proxy, vous devez être membre du rôle serveur fixe sysadmin ou bien du rôle SQLAgentOperatorRole, SQLAgentReaderRole ou SQLAgentUserRole dans la base de données msdb. Vous créez un compte proxy en exécutant une requête Transact-SQL ou à l'aide de la boîte de dialogue Nouveau compte de proxy (New Proxy Account) dans SQL Server Management Studio. Nous utiliserons la boîte de dialogue Nouveau compte de proxy (New Proxy Account). Dans la page Général (General), spécifiez le nom et les informations d'identification du nouveau compte proxy. Nous nommons le compte Package proxy et sélectionnons des informations d'identification existantes, User1, qui contiennent les informations d'authentification. Gardez à l'esprit que les informations d'identification sélectionnées doivent permettre à l'Agent SQL Server d'exécuter le travail en tant que compte qui a créé le package ou qui dispose des autorisations requises. Vous devez également spécifier le sous-système pour lequel le proxy est activé. Dans la mesure où le travail exécute un package, nous sélectionnons le sous-système Package SQL Server Integration Services (SQL Server Integration Services Package). La description du proxy est facultative. Dans la page Serveurs principaux (Principals), vous pouvez ajouter ou supprimer des rôles afin d'accorder l'accès au compte proxy. Les membres du rôle serveur fixe sysadmin ont un accès automatique. Les informations d'identification User1 que nous avons spécifiées pour le compte proxy sont répertoriées sous le nœud Informations d'identification (Credentials) dans l'Explorateur d'objets. Vous pouvez créer des informations d'identification en exécutant une requête Transact-SQL ou à l'aide de la boîte de dialogue Nouvelles informations d'identification (New Credentials). Cette vidéo vous a expliqué comment résoudre les problèmes liés à un package qui n'est pas exécuté lorsqu'il est appelé à partir d'une étape de travail de l'Agent SQL Server. La vidéo a traité la création d'un compte proxy, la modification du paramètre de propriété ProtectionLevel du package, l'enregistrement de données sensibles dans un fichier de configuration de package et le stockage d'un package dans la base de données SQL Server msdb. Nous vous remercions d'avoir regardé cette vidéo. Nous espérons que vous l'avez trouvée intéressante et que vous reviendrez à la page Web pour regarder d'autres vidéos liées à Microsoft SQL Server. |