sql >> Databasteknik >  >> RDS >> Sqlserver

SSIS-paketet körs inte som 32-bitars i SQL Server 2012

Som standard kommer allt att köras i 64 bitar på servrarna. För att ändra detta beteende måste du ange att 32-bitarsversionen av dtexec borde användas. För 2012 SSISDB har vi två enkla sätt att anropa våra paket:SQL Agent och catalog.start_execution metod.

catalog.start_execution

För enstaka paketkörningar kan du hitta paketet i SSISDB-katalogen och högerklicka på dem för att Execute...

I den resulterande popup-dialogrutan måste du gå till fliken Avancerat och kontrollera 32-bit runtime låda. Detta skulle göras vid varje körning av paketet.

Bakom kulisserna skulle SQL som guiden genererar se ut 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 är @use32bitruntime parametern skickas ett värde på True för att indikera att den ska köras i 32 utrymmen.

SQL-agent

För återkommande paketkörningar använder vi vanligtvis ett schemaläggningsverktyg. För att komma till 32-bitars inställningen för ett paket i agent, är det i princip samma klicksökväg förutom att du först måste klicka på fliken Konfiguration och sedan klicka på fliken Avancerat för att välja 32-bit runtime

Definitionen av jobbsteg skulle se ut ungefär som

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 ser att i @command-anropet genererar guiden /X86 anrop som är det speciella argumentet reserverat för SQL Agent (kontrollera BOL-länken i början) för att indikera om 32- eller 64-bitarsversionen av dtexec ska användas. En kommandoradsanrop skulle kräva att vi uttryckligen använder korrekt dtexec. Som standard kommer 64-bitars dtexec att listas först i din PATH-miljö

64-bitars dtexec-platser

  • 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-bitars dtexec-platser

  • 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

Ytterligare felsökningsdrivrutiner

Den körs på en server, inte på en annan.

Steg 1 - verifiera att du har installerat drivrutinerna. Dumt, uppenbart men det har funnits många frågor där folk av misstag trodde att ett SSIS-paket/.ispac också skulle distribuera alla refererade sammansättningar. Det är inte nuget så nej, alla förutsättningar skulle behöva installeras och installeras korrekt (sett folk försöka kopiera sammansättningar till GAC istället för att använda verktyget)

Steg 2 – verifiera att drivrutinsinstallationen stämmer överens med servrarna. Återigen, det verkar uppenbart men jag har upplevt smärta, generellt VS_NEEDSNEWMETADATA, på en punktskillnad i drivrutinsversion 4.0.2.013 gav andra resultat än 4.0.2.014

Steg 3 - Se till att alla DSN som du har definierat har definierats i rätt utrymme. Den här biter människor av ett antal anledningar. Jag tror att det var inte förrän Server 2012 som du bara kunde komma till 32-bitarsversionen av odbcad32.exe (körbar relaterad till Administrativa verktyg -> Datakällor (ODBC)) var genom att hitta den på filsystemet. Desto mer förvirrande är den körbara filen heter odbcad32.exe oavsett om den är i System32 eller SysWOW64 och de två mapparna är för 64-bitars drivrutiner respektive 32-bitars drivrutiner. Ja, framtida läsare, det är inget stavfel. 64-versionen av applikationer finns i System32, 32-bitarsversionerna är i SysWOW64. Det var ett designbeslut avsett att minimera påverkan.

På test- och liveservern, kör C:\Windows\SysWOW64\odbcad32.exe Hitta dina FoxPro-drivrutiner och relaterade DSN:er, är de som förväntat?

Steg 4 - Konstig behörighetskontroll. Logga in på båda servrarna som ett "normalt" konto och kör paketet från kommandoraden. Upprepa det här steget men kör det med Agent, med vilken proxy du än har definierat eller inte. Om den första fungerar men den senare misslyckas, indikerar det vanligtvis ett behörighetsproblem. Det kan vara så att SQL Server- eller Agent-kontot inte kan komma åt vilken mapp som drivrutinen installerades till. Det kan vara så att kontot behöver InteractWithDesktop-tillståndet eller någon annan behörighet som nekas eller inte uttryckligen beviljas.



  1. Hur man läser sql-fråga till pandas dataframe / python / django

  2. Codeigniter kan inte ta bort rader från databastabellen med hjälp av join-metoden

  3. Vilken version av .Net framework levereras med SQL Server 2008?

  4. Hibernate:Skapa/uppdatera db-tabellerna automatiskt baserat på entitetsklasser