Par défaut, tout fonctionnera en 64 bits sur les serveurs. Pour modifier ce comportement, vous devez indiquer que la version 32 bits de dtexec Devrait être utilisé. Pour la SSISDB 2012, nous avons deux manières simples d'invoquer nos packages :l'agent SQL et le catalog.start_execution méthode.
catalog.start_execution
Pour les exécutions de packages à service unique, vous pouvez trouver le package dans le catalogue SSISDB et cliquer dessus avec le bouton droit pour Execute...
Dans la boîte de dialogue contextuelle résultante, vous devrez accéder à l'onglet Avancé et vérifier le 32-bit runtime boîte. Cela serait fait à chaque exécution du package.
Dans les coulisses, le SQL généré par l'assistant ressemblerait à
DECLARE @execution_id bigint
EXEC [SSISDB].[catalog].[create_execution]
@package_name = N'Package.dtsx'
, @execution_id = @execution_id OUTPUT
, @folder_name = N'POC'
, @project_name = N'SSISConfigMixAndMatch'
, @use32bitruntime = True
, @reference_id = NULL
SELECT
@execution_id
DECLARE @var0 smallint = 1
EXEC [SSISDB].[catalog].[set_execution_parameter_value]
@execution_id
, @object_type = 50
, @parameter_name = N'LOGGING_LEVEL'
, @parameter_value = @var0
EXEC [SSISDB].[catalog].[start_execution]
@execution_id
GO
Comme vous pouvez le voir, le @use32bitruntime Le paramètre reçoit la valeur True pour indiquer qu'il doit s'exécuter dans l'espace 32.
Agent SQL
Pour les exécutions récurrentes de packages, nous utilisons généralement un outil de planification. Pour accéder au paramètre 32 bits d'un package dans l'agent, il s'agit essentiellement du même chemin de clic, sauf que vous devez d'abord cliquer sur l'onglet Configuration et puis cliquez sur l'onglet Avancé pour sélectionner 32-bit runtime
La définition de l'étape de travail ressemblerait à quelque chose comme
EXEC msdb.dbo.sp_add_jobstep
@job_name = N'Do it'
, @step_name = N'Run in 32bit'
, @step_id = 1
, @cmdexec_success_code = 0
, @on_success_action = 1
, @on_fail_action = 2
, @retry_attempts = 0
, @retry_interval = 0
, @os_run_priority = 0
, @subsystem = N'SSIS'
, @command = N'/ISSERVER "\"\SSISDB\POC\SSISConfigMixAndMatch\Package.dtsx\"" /SERVER "\".\dev2014\"" /X86 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E'
, @database_name = N'master'
, @flags = 0
Vous verrez que dans l'appel @command, l'assistant génère le /X86 call qui est l'argument spécial réservé à SQL Agent (vérifiez le lien BOL au début) pour indiquer si la version 32 ou 64 bits de dtexec doit être utilisée. Une invocation en ligne de commande nous obligerait à utiliser explicitement le dtexec correct. Par défaut, le dtexec 64 bits sera répertorié en premier dans votre environnement PATH
Emplacements dtexec 64 bits
- C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Emplacements dtexec 32 bits
- C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Autres pilotes de dépannage
Il s'exécute sur un serveur, pas sur un autre.
Étape 1 - vérifiez que vous avez installé les pilotes. Stupide, évident mais il y a eu de nombreuses questions où les gens pensaient à tort que le déploiement d'un package SSIS/.ispac déploierait également tous les assemblys référencés. Ce n'est pas nuget donc non, tous les prérequis devraient être installés, et installés correctement (on a vu des gens essayer de copier des assemblages dans le GAC au lieu d'utiliser l'outil)
Étape 2 - vérifiez que l'installation du pilote correspond à tous les serveurs. Encore une fois, cela semble évident, mais j'ai ressenti de la douleur, généralement VS_NEEDSNEWMETADATA, sur une différence de point dans la version du pilote, la version 4.0.2.013 a produit des résultats différents de 4.0.2.014
Étape 3 - Assurez-vous que tous les DSN que vous avez définis ont été définis dans l'espace correct. Celui-ci mord les gens pour un certain nombre de raisons. Je pense que ce n'est qu'à partir de Server 2012 que vous ne pouviez accéder qu'à la version 32 bits de odbcad32.exe (exécutable lié à Outils d'administration -> Sources de données (ODBC)) en le trouvant sur le système de fichiers. D'autant plus déroutant que l'exécutable s'appelle odbcad32.exe, qu'il se trouve dans System32 ou SysWOW64 et que ces deux dossiers concernent respectivement les pilotes 64 bits et les pilotes 32 bits. Oui, futurs lecteurs, ce n'est pas une faute de frappe. La version 64 des applications est en System32, les versions 32 bits sont en SysWOW64. C'était une décision de conception visant à minimiser l'impact.
Sur le serveur de test et en direct, exécutez C:\Windows\SysWOW64\odbcad32.exe Trouvez vos pilotes FoxPro et les DSN associés, sont-ils comme prévu ?
Étape 4 - Vérification d'autorisation étrange. Connectez-vous aux deux serveurs en tant que compte "normal" et exécutez le package à partir de la ligne de commande. Répétez cette étape mais exécutez-la à l'aide de l'agent, avec le proxy que vous avez défini ou non. Si le premier fonctionne mais que le second échoue, cela indique généralement un problème d'autorisation. Il se peut que le compte SQL Server ou Agent ne puisse pas accéder au dossier dans lequel le pilote a été installé. Il se peut que ledit compte ait besoin de l'autorisation InteractWithDesktop ou d'une autre autorisation refusée ou non explicitement accordée.
