Standardmäßig läuft auf den Servern alles in 64 Bit. Um dieses Verhalten zu ändern, müssen Sie angeben, dass die 32-Bit-Version von dtexec sollte benutzt werden. Für die 2012 SSISDB haben wir zwei einfache Möglichkeiten, unsere Pakete aufzurufen:SQL Agent und catalog.start_execution Methode.
catalog.start_execution
Für Single-Serving-Paketausführungen finden Sie das Paket im SSISDB-Katalog und klicken Sie mit der rechten Maustaste darauf, um Execute...
Im resultierenden Popup-Dialog müssen Sie zur Registerkarte Erweitert gehen und die 32-bit runtime überprüfen Kasten. Dies würde bei jeder Ausführung des Pakets erfolgen.
Hinter den Kulissen würde das vom Assistenten generierte SQL so aussehen
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
Wie Sie sehen können, ist die Datei @use32bitruntime -Parameter wird der Wert True übergeben, um anzugeben, dass er in 32-Zeilen ausgeführt werden soll.
SQL-Agent
Für wiederkehrende Paketläufe verwenden wir in der Regel ein Planungstool. Um zur 32-Bit-Einstellung für ein Paket im Agenten zu gelangen, ist es im Grunde derselbe Klickpfad, außer dass Sie zuerst auf die Registerkarte Konfiguration und dann klicken müssen Klicken Sie auf die Registerkarte Erweitert, um 32-bit runtime auszuwählen
Die Job-Step-Definition würde in etwa so aussehen
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
Sie werden sehen, dass der Assistent im @command-Aufruf den /X86 generiert call, welches das besondere Argument ist, das für SQL Agent reserviert ist (überprüfen Sie den BOL-Link am Anfang), um anzugeben, ob die 32- oder 64-Bit-Version von dtexec verwendet werden soll. Ein Befehlszeilenaufruf würde erfordern, dass wir explizit die korrekte dtexec verwenden. Standardmäßig wird die 64-Bit-dtexec zuerst in Ihrer PATH-Umgebung aufgelistet
64-Bit-dtexec-Speicherorte
- C:\Programme\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Programme\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Programme\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Programme\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
32-Bit-dtexec-Speicherorte
- C:\Programme (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Programme (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Programme (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Programme (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Weitere Treiber zur Fehlerbehebung
Es läuft auf einem Server, auf einem anderen nicht.
Schritt 1 – Überprüfen Sie, ob Sie die Treiber installiert haben. Dumm, offensichtlich, aber es gab viele Fragen, bei denen die Leute fälschlicherweise dachten, dass die Bereitstellung eines SSIS-Pakets/.ispac auch alle referenzierten Assemblys bereitstellen würde. Es ist kein Nuget, also nein, alle Voraussetzungen müssten installiert und richtig installiert werden (man hat gesehen, wie Leute versucht haben, Assemblys in den GAC zu kopieren, anstatt das Tool zu verwenden)
Schritt 2 – Überprüfen Sie, ob die Treiberinstallation serverübergreifend übereinstimmt. Auch hier scheint es offensichtlich zu sein, aber ich habe Schmerzen, im Allgemeinen VS_NEEDSNEWMETADATA, bei einem Punktunterschied in der Treiberversion Version 4.0.2.013 erlebt, die andere Ergebnisse als 4.0.2.014 erzeugt
Schritt 3 – Stellen Sie sicher, dass alle von Ihnen definierten DSNs im richtigen Bereich definiert wurden. Dieser beißt Menschen aus mehreren Gründen. Ich denke, bis Server 2012 konnte man nur auf die 32-Bit-Version von odbcad32.exe (ausführbare Datei im Zusammenhang mit Verwaltungstools -> Datenquellen (ODBC)) zugreifen, indem man sie im Dateisystem fand. Umso verwirrender ist, dass die ausführbare Datei odbcad32.exe heißt, unabhängig davon, ob sie sich in System32 oder SysWOW64 befindet und diese beiden Ordner für die 64-Bit-Treiber bzw. die 32-Bit-Treiber sind. Ja, zukünftige Leser, das ist kein Tippfehler. Die 64-Version der Anwendungen befindet sich in System32, die 32-Bit-Versionen in SysWOW64. Es war eine Designentscheidung, die darauf abzielte, die Auswirkungen zu minimieren.
Führen Sie auf dem Test- und Live-Server C:\Windows\SysWOW64\odbcad32.exe aus Finden Sie Ihre FoxPro-Treiber und die zugehörigen DSNs, sind sie wie erwartet?
Schritt 4 – Seltsame Berechtigungsprüfung. Melden Sie sich bei beiden Servern als "normales" Konto an und führen Sie das Paket über die Befehlszeile aus. Wiederholen Sie diesen Schritt, führen Sie ihn jedoch mit dem Agenten aus, unabhängig davon, welchen Proxy Sie möglicherweise definiert haben oder nicht. Wenn ersteres funktioniert, letzteres jedoch fehlschlägt, deutet dies normalerweise auf ein Berechtigungsproblem hin. Es kann sein, dass das SQL Server- oder Agent-Konto nicht auf den Ordner zugreifen kann, in dem der Treiber installiert wurde. Es kann sein, dass dieses Konto die InteractWithDesktop-Berechtigung oder eine andere Berechtigung benötigt, die verweigert oder nicht explizit gewährt wird.
