Domyślnie wszystko na serwerach będzie działać w wersji 64-bitowej. Aby zmienić to zachowanie, musisz wskazać, że 32-bitowa wersja dtexec powinien być używany. W przypadku bazy danych SSISDB 2012 mamy dwa proste sposoby wywoływania naszych pakietów:agenta SQL i catalog.start_execution metoda.
catalog.start_execution
W przypadku pojedynczych uruchomień pakietów obsługujących można znaleźć pakiet w katalogu SSISDB i kliknąć go prawym przyciskiem myszy, aby Execute...
W wyświetlonym oknie dialogowym musisz przejść do zakładki Zaawansowane i sprawdzić 32-bit runtime skrzynka. Byłoby to zrobione przy każdym uruchomieniu pakietu.
Za kulisami wygenerowany przez kreatora SQL wyglądałby tak
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
Jak widać, @use32bitruntime parametrowi jest przekazywana wartość True, aby wskazać, że powinien działać w 32 miejscach.
Agent SQL
W przypadku cyklicznych uruchomień pakietów zazwyczaj używamy narzędzia do planowania. Aby przejść do 32-bitowego ustawienia pakietu w agencie, jest to w zasadzie ta sama ścieżka kliknięcia, z wyjątkiem tego, że najpierw musisz kliknąć kartę Konfiguracja, a następnie następnie kliknij kartę Zaawansowane, aby wybrać 32-bit runtime
Definicja etapu pracy wyglądałaby mniej więcej tak
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
Zobaczysz, że w wywołaniu @command kreator generuje /X86 wywołanie, które jest specjalnym argumentem zarezerwowanym dla agenta SQL (sprawdź łącze BOL na początku), aby wskazać, czy należy użyć 32-bitowej czy 64-bitowej wersji dtexec. Wywołanie wiersza poleceń wymagałoby od nas jawnego użycia poprawnego dtexec. Domyślnie 64-bitowy dtexec będzie wyświetlany jako pierwszy w środowisku PATH
64-bitowe lokalizacje dtexec
- 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
32-bitowe lokalizacje dtexec
- 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
Dalsze rozwiązywanie problemów ze sterownikami
Działa na jednym serwerze, nie na innym.
Krok 1 — sprawdź, czy zainstalowałeś sterowniki. To głupie, oczywiste, ale było wiele pytań, w których ludzie błędnie myśleli, że wdrożenie pakietu SSIS/.ispac spowoduje również wdrożenie wszystkich wymienionych zestawów. To nie jest nuget, więc nie, wszystkie wymagania wstępne musiałyby zostać zainstalowane i poprawnie zainstalowane (widziano, że ludzie próbują kopiować zestawy do GAC zamiast używać narzędzia)
Krok 2 — sprawdź, czy instalacja sterownika jest zgodna z różnymi serwerami. Znowu wydaje się to oczywiste, ale doświadczyłem bólu, generalnie VS_NEEDSNEWMETADATA, w punkcie różnicy w wersji sterownika w wersji 4.0.2.013 dały inne wyniki niż 4.0.2.014
Krok 3 — Upewnij się, że wszystkie zdefiniowane nazwy DSN zostały zdefiniowane w odpowiednim miejscu. Ten gryzie ludzi z wielu powodów. Myślę, że dopiero w Server 2012 można było uzyskać dostęp tylko do 32-bitowej wersji odbcad32.exe (plik wykonywalny związany z Narzędziami administracyjnymi -> Źródła danych (ODBC)) przez znalezienie go w systemie plików. Tym bardziej zagmatwane jest to, że plik wykonywalny nosi nazwę odbcad32.exe, niezależnie od tego, czy znajduje się w System32, czy SysWOW64, a te dwa foldery dotyczą odpowiednio sterowników 64-bitowych i 32-bitowych. Tak, przyszli czytelnicy, to nie jest literówka. Wersja 64 aplikacji znajduje się w System32, wersje 32-bitowe znajdują się w SysWOW64. Była to decyzja projektowa mająca na celu zminimalizowanie wpływu.
Na serwerze testowym i na żywo uruchom C:\Windows\SysWOW64\odbcad32.exe Znajdź sterowniki FoxPro i powiązane DSN, czy są zgodne z oczekiwaniami?
Krok 4 - Dziwne sprawdzenie uprawnień. Zaloguj się do obu serwerów jako „normalne” konto i uruchom pakiet z wiersza poleceń. Powtórz ten krok, ale wykonaj go za pomocą Agenta, z dowolnym serwerem proxy, który zdefiniowałeś lub nie. Jeśli pierwszy działa, ale drugi się nie powiedzie, zwykle oznacza to problem z uprawnieniami. Możliwe, że konto SQL Server lub Agent nie ma dostępu do folderu, w którym zainstalowano sterownik. Może się zdarzyć, że wspomniane konto wymaga uprawnienia InteractWithDesktop lub innego uprawnienia, które jest odmawiane lub nie jest jawnie przyznane.
