Per impostazione predefinita, tutto verrà eseguito a 64 bit sui server. Per modificare questo comportamento, devi indicare che la versione a 32 bit di dtexec dovrebbe essere usato. Per il SSISDB 2012, abbiamo due semplici modi per invocare i nostri pacchetti:SQL Agent e catalog.start_execution metodo.
catalog.start_execution
Per le esecuzioni di pacchetti a servizio singolo, puoi trovare il pacchetto nel catalogo SSISDB e fare clic con il pulsante destro del mouse per Execute...
Nella finestra di dialogo risultante, dovrai andare alla scheda Avanzate e controllare il 32-bit runtime scatola. Questo verrebbe fatto ad ogni esecuzione del pacchetto.
Dietro le quinte, l'SQL generato dalla procedura guidata sarebbe simile a
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
Come puoi vedere, il @use32bitruntime al parametro viene passato un valore di True per indicare che deve essere eseguito in 32 spazi.
Agente SQL
Per esecuzioni di pacchetti ricorrenti, generalmente utilizziamo uno strumento di pianificazione. Per ottenere l'impostazione a 32 bit per un pacchetto nell'agente, è fondamentalmente lo stesso percorso di clic, tranne per il fatto che devi prima fare clic sulla scheda Configurazione e poi fare clic sulla scheda Avanzate per selezionare 32-bit runtime
La definizione della fase di lavoro sarebbe simile a
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
Vedrai che nella @command call, la procedura guidata genera il /X86 call che è l'argomento speciale riservato per SQL Agent (controlla il collegamento BOL all'inizio) per indicare se deve essere utilizzata la versione a 32 o 64 bit di dtexec. Una chiamata alla riga di comando richiederebbe l'uso esplicito di dtexec corretto. Per impostazione predefinita, il dtexec a 64 bit verrà elencato per primo nel tuo ambiente PATH
Posizioni dtexec a 64 bit
- C:\Programmi\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Programmi\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Programmi\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Programmi\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Posizioni dtexec a 32 bit
- C:\Programmi (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Programmi (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Programmi (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Programmi (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Ulteriore risoluzione dei problemi dei driver
Funziona su un server, non su un altro.
Passaggio 1:verifica di aver installato i driver. Sciocco, ovvio, ma ci sono state molte domande in cui le persone hanno erroneamente pensato che la distribuzione di un pacchetto SSIS/.ispac avrebbe distribuito anche tutti gli assembly a cui si fa riferimento. Non è nuget quindi no, tutti i prerequisiti dovrebbero essere installati e installati correttamente (visto che le persone cercano di copiare gli assembly nel GAC invece di usare lo strumento)
Passaggio 2:verifica che l'installazione del driver corrisponda tra i server. Ancora una volta, sembra ovvio ma ho sperimentato dolore, generalmente VS_NEEDSNEWMETADATA, su una differenza di punto nella versione del driver 4.0.2.013 ha prodotto risultati diversi rispetto a 4.0.2.014
Passaggio 3:assicurarsi che tutti i DSN definiti siano stati definiti nello spazio corretto. Questo morde le persone per una serie di motivi. Penso che non sia stato fino a Server 2012 che è stato possibile ottenere solo la versione a 32 bit di odbcad32.exe (eseguibile relativo a Strumenti di amministrazione -> Origini dati (ODBC)) trovandolo nel file system. Tanto più confuso è che l'eseguibile si chiama odbcad32.exe indipendentemente dal fatto che sia in System32 o SysWOW64 e quelle due cartelle sono rispettivamente per i driver a 64 bit e i driver a 32 bit. Sì, futuri lettori, non è un errore di battitura. La versione 64 delle applicazioni è in System32, le versioni a 32 bit sono in SysWOW64. È stata una decisione progettuale volta a ridurre al minimo l'impatto.
Sul server di prova e live, esegui C:\Windows\SysWOW64\odbcad32.exe Trova i tuoi driver FoxPro e i relativi DSN, sono come previsto?
Passaggio 4:strano controllo delle autorizzazioni. Accedere a entrambi i server come account "normali" ed eseguire il pacchetto dalla riga di comando. Ripeti questo passaggio ma eseguilo utilizzando Agent, con qualsiasi proxy tu possa aver definito o meno. Se il primo funziona ma il secondo fallisce, di solito indica un problema di autorizzazione. È possibile che l'account SQL Server o Agent non riesca ad accedere alla cartella in cui è stato installato il driver. È possibile che detto account necessiti dell'autorizzazione InteractWithDesktop o di un'altra autorizzazione negata o non concessa in modo esplicito.
