De forma predeterminada, todo se ejecutará en 64 bits en los servidores. Para cambiar este comportamiento, debe indicar que la versión de 32 bits de dtexec debería ser usado. Para SSISDB 2012, tenemos dos formas sencillas de invocar nuestros paquetes:SQL Agent y catalog.start_execution método.
catalog.start_execution
Para ejecuciones de paquetes de una sola porción, puede encontrar el paquete en el catálogo de SSISDB y hacer clic derecho sobre ellos para Execute...
En el cuadro de diálogo emergente resultante, deberá ir a la pestaña Avanzado y verificar el 32-bit runtime caja. Esto se haría en cada ejecución del paquete.
Detrás de escena, el SQL que genera el asistente se vería como
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
Como puede ver, el @use32bitruntime al parámetro se le pasa un valor de True para indicar que debe ejecutarse en 32 espacios.
Agente SQL
Para ejecuciones recurrentes de paquetes, generalmente usamos una herramienta de programación. Para llegar a la configuración de 32 bits para un paquete en el agente, es básicamente la misma ruta de clic, excepto que primero debe hacer clic en la pestaña Configuración y luego haga clic en la pestaña Avanzado para seleccionar 32-bit runtime
La definición del paso del trabajo se vería como
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
Verá que en la llamada @command, el asistente genera el /X86 call, que es el argumento especial reservado para el Agente SQL (verifique el enlace BOL al principio) para indicar si se debe usar la versión de 32 o 64 bits de dtexec. Una invocación de la línea de comando requeriría que usemos explícitamente el dtexec correcto. De forma predeterminada, el dtexec de 64 bits aparecerá primero en su entorno PATH
Ubicaciones dtexec de 64 bits
- C:\Archivos de programa\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Archivos de programa\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Archivos de programa\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Archivos de programa\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Ubicaciones dtexec de 32 bits
- C:\Archivos de programa (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Archivos de programa (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Archivos de programa (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Archivos de programa (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Otros controladores de solución de problemas
Se ejecuta en un servidor, no en otro.
Paso 1:verifique que haya instalado los controladores. Tonto, obvio, pero ha habido muchas preguntas en las que las personas pensaron erróneamente que implementar un paquete SSIS/.ispac también implementaría todos los ensamblajes a los que se hace referencia. No es nuget, así que no, todos los requisitos previos deberían instalarse e instalarse correctamente (se ha visto que las personas intentan copiar ensamblajes en el GAC en lugar de usar la herramienta)
Paso 2:verifique que la instalación del controlador coincida en todos los servidores. Una vez más, parece obvio, pero he experimentado dolor, generalmente VS_NEEDSNEWMETADATA, en un punto de diferencia en la versión del controlador, la versión 4.0.2.013 produjo resultados diferentes a los de la 4.0.2.014
Paso 3:asegúrese de que todos los DSN que haya definido se hayan definido en el espacio correcto. Este muerde a la gente por varias razones. Creo que no fue hasta Server 2012 que solo pudo acceder a la versión de 32 bits de odbcad32.exe (ejecutable relacionado con Herramientas administrativas -> Fuentes de datos (ODBC)) al encontrarlo en el sistema de archivos. Aún más confuso es que el ejecutable se llama odbcad32.exe independientemente de si está en System32 o SysWOW64 y esas dos carpetas son para los controladores de 64 bits y los controladores de 32 bits respectivamente. Sí, futuros lectores, eso no es un error tipográfico. La versión 64 de las aplicaciones está en System32, las versiones de 32 bits están en SysWOW64. Fue una decisión de diseño destinada a minimizar el impacto.
En el servidor de prueba y en vivo, ejecute C:\Windows\SysWOW64\odbcad32.exe Encuentre sus controladores FoxPro y los DSN relacionados, ¿son los esperados?
Paso 4:verificación de permisos extraños. Inicie sesión en ambos servidores como una cuenta "normal" y ejecute el paquete desde la línea de comandos. Repita este paso, pero ejecútelo usando el Agente, con cualquier proxy que haya definido o no. Si el primero funciona pero el segundo falla, eso generalmente indica un problema de permisos. Es posible que la cuenta de SQL Server o Agent no pueda acceder a la carpeta en la que se instaló el controlador. Puede ser que dicha cuenta necesite el permiso InteractWithDesktop o algún otro permiso que se niega o no se otorga explícitamente.
