Ho due pacchetti SSIS che vengono programmati durante la notte (tramite SQL Server Agent) come parte di una distribuzione SSIS più ampia, senza problemi. Tutto utilizza l'autenticazione di Windows e il processo pianificato è di proprietà di un amministratore di sistema (beh, io) ed eseguito come account del servizio agente di SQL Server.
Quindi, i dati essenzialmente vanno source system ~> transit db ~> staging ~> NDSdall'oggi al domani.
I due pacchetti SSIS a cui tengo, gestiscono rispettivamente le parti transit db ~> staginge staging ~> NDS, per un insieme specifico di dati.
Un utente di dominio (non amministratore di sistema) fa qualcosa nel source systeme che inserisce i dati interessanti nel transit db, quindi ho bisogno di un modo per recuperare questi dati aggiornati durante l'orario di lavoro per aggiornare il NDS: è stato deciso che il modo più semplice per questa persona di innescare tale ETL, facendo clic su un pulsante in una cartella di lavoro Excel abilitata per le macro, si collega a SQL Server tramite ODBC (utilizzando l'autenticazione di Windows) ed esegue una procedura memorizzata.
La procedura memorizzata è simile alla seguente:
create procedure dbo.UpdateMaterialInventory
as
begin
execute msdb.dbo.UpdateMaterialInventory;
endLa procedura memorizzata "sorella" in [msdb] è simile alla seguente:
create procedure dbo.UpdateMaterialInventory
with execute as 'SqlAgentProxy'
as
begin
execute msdb.dbo.sp_start_job N'NDS-ManualMaterialInventory';
endQuesto utente [SqlAgentProxy] è un utente Windows che ho creato in [msdb] al di fuori dell'accesso dell'utente del dominio, al quale ho concesso l' executeautorizzazione a questa UpdateMaterialInventoryprocedura. Questo evita di dover concedere l' executeautorizzazione all'utente del dominio msdb.dbo.sp_start_job, il che sarebbe eccessivo.
Il processo di SQL Agent NDS-ManualMaterialInventoryè di proprietà dell'utente del dominio e prevede 2 passaggi, ciascuno di tipo [Pacchetto SQL Server Integration Services], impostato su Esegui come SSISProxy .
SSISProxyè un proxy di SQL Server Agent mappato al sottosistema [SQL Server Integration Services Package], utilizzando il nome della credenziale SSISProxyCredentials. L'accesso dell'utente del dominio è stato aggiunto ai principali dell'account proxy .
Sono SSISProxyCredentialsstati creati con l' identità dello stesso utente di dominio che esegue l'intero SSL ETL durante la notte e la sua password è stata verificata quadrupla.
Ora, se eseguo questo:
execute as login=N'DOMAIN\thatperson'
exec NDS.dbo.UpdateMaterialInventory;
goOttengo questo risultato:
Job 'NDS-ManualMaterialInventory' started successfully.Tuttavia, la storia del lavoro racconta una storia molto meno incoraggiante:
The job failed. The Job was invoked by User DOMAIN\thatperson.
The last step to run was step 1 (Extract).E i dettagli del passaggio 1:
Executed as user: {domain user that runs SSIS ETL overnight}.
Microsoft (R) SQL Server Execute Package Utility Version 12.0.4100.1 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 2:18:50 PM Failed to execute IS server package because of error 0x80131904.
Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.
Source: .Net SqlClient Data Provider
Started: 2:18:50 PM Finished: 2:18:51 PM Elapsed: 0.094 seconds.
The package execution failed.
The step failed.Il lavoro ha esito negativo e nulla viene registrato da nessuna parte.
Se cambio il proprietario del lavoro per essere me stesso e cambio i passaggi ' run come essere l'account del servizio agente di SQL Server, il lavoro viene eseguito, ha esito positivo e registra 1.067 righe in [Metadata]. [Dbo]. [Sysssislog].
Sembra che ci sia qualcosa di sbagliato nel modo in cui sono impostati il proxy / le credenziali. Quale parte sto sbagliando?