sql >> Database teknologi >  >> RDS >> Sqlserver

SSIS-pakke kører ikke som 32bit i SQL Server 2012

Som standard vil alt køre i 64 bit på serverne. For at ændre denne adfærd skal du angive, at 32bit-versionen af ​​dtexec skal bruges. For 2012 SSISDB har vi to nemme måder at kalde vores pakker på:SQL Agent og catalog.start_execution metode.

catalog.start_execution

For enkelte serveringspakkekørsel kan du finde pakken i SSISDB-kataloget og højreklikke på dem for at Execute...

I den resulterende pop op-dialog skal du gå til fanen Avanceret og kontrollere 32-bit runtime boks. Dette ville blive gjort ved hver kørsel af pakken.

Bag kulisserne ville den SQL, som guiden genererer, se ud som

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

Som du kan se, er @use32bitruntime parameter sendes en værdi på True for at angive, at den skal køre i 32 mellemrum.

SQL-agent

Til tilbagevendende pakkekørsel bruger vi generelt et planlægningsværktøj. For at komme til 32-bit indstillingen for en pakke i agent, er det grundlæggende den samme kliksti, bortset fra at du først skal klikke på fanen Konfiguration og derefter klik på fanen Avanceret for at vælge 32-bit runtime

Jobtrinsdefinitionen ville ligne

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

Du vil se, at i @command-kaldet genererer guiden /X86 kald, som er det specielle argument, der er reserveret til SQL Agent (tjek BOL-linket i begyndelsen) for at angive, om 32- eller 64-bit versionen af ​​dtexec skal bruges. En kommandolinjekald vil kræve, at vi eksplicit bruger korrekt dtexec. Som standard vil 64 bit dtexec'en blive vist først i dit PATH-miljø

64 bit dtexec-placeringer

  • 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 bit dtexec-placeringer

  • 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

Yderligere fejlfinding af drivere

Det kører på én server, ikke på en anden.

Trin 1 - bekræft, at du har installeret driverne. Dumt, indlysende, men der har været mange spørgsmål, hvor folk fejlagtigt troede, at implementering af en SSIS-pakke/.ispac også ville implementere alle de refererede samlinger. Det er ikke nuget, så nej, alle forudsætningerne skal installeres og installeres korrekt (set folk prøve at kopiere samlinger ind i GAC i stedet for at bruge værktøjet)

Trin 2 - kontroller, at driverinstallationen matcher på tværs af servere. Igen, det virker indlysende, men jeg har oplevet smerter, generelt VS_NEEDSNEWMETADATA, på en punktforskel i driverversion 4.0.2.013 gav andre resultater end 4.0.2.014

Trin 3 - Sørg for, at alle DSN'er, du har defineret, blev defineret på det rigtige sted. Denne bider folk af en række årsager. Jeg tror, ​​det var først i Server 2012, at du kun kunne komme til 32bit-versionen af ​​odbcad32.exe (eksekverbar relateret til Administrative Tools -> Data Sources (ODBC)) var ved at finde den på filsystemet. Så meget desto mere forvirrende er det, at den eksekverbare er navngivet odbcad32.exe, uanset om den er i System32 eller SysWOW64, og de to mapper er til henholdsvis 64 bit drivere og 32 bit drivere. Ja, fremtidige læsere, det er ikke en tastefejl. 64-versionen af ​​applikationer er i System32, 32-bit-versionerne er i SysWOW64. Det var en designbeslutning, der skulle minimere påvirkningen.

På test- og liveserveren skal du køre C:\Windows\SysWOW64\odbcad32.exe Find dine FoxPro-drivere og de relaterede DSN'er, er de som forventet?

Trin 4 - Underligt tilladelsestjek. Log på begge servere som en "normal" konto og kør pakken fra kommandolinjen. Gentag dette trin, men udfør det ved hjælp af Agent, med den proxy, du måtte have defineret eller ikke. Hvis det første virker, men det sidste mislykkes, indikerer det normalt et tilladelsesproblem. Det kan være, at SQL Server- eller Agent-kontoen ikke kan få adgang til den mappe, driveren er installeret i. Det kan være, at nævnte konto har brug for InteractWithDesktop-tilladelsen eller en anden tilladelse, der er nægtet eller ikke eksplicit givet.



  1. Sådan viser du alle de tabeller, der bruges i en bestemt lagret procedure i Oracle

  2. Tæl antallet af rækker i golang

  3. MySQL -- Opdater hvis der findes andet indsæt med to nøgler

  4. Opret PDF-filer med PLSQL i Oracle