Risoluzione dei problemi: Esecuzione di un pacchetto SSIS con SQL Server Agent (video di SQL Server)

Si applica a: Microsoft SQL Server Integration Services

Autori: Carla Sabotta, Microsoft Corporation

Durata: 00.12.12 Dimensioni: 9,50 MB Tipo: WMV

Guarda il video

Argomenti correlati: Un pacchetto SSIS non viene eseguito quando viene chiamato da un passaggio del processo di SQL Server Agent Utilità dtexec Procedura: Aggiunta di una configurazione di pacchetto Impostazione del livello di protezione dei pacchetti Utilizzo dei ruoli di Integration Services

Altri video: Procedura: Automazione dell'esecuzione di un pacchetto SSIS utilizzando SQL Server Agent (video di SQL Server)

Riepilogo del video

In questo video viene illustrato come risolvere i problemi relativi alla mancata esecuzione di un pacchetto di SQL Server Integration Services quando questo viene chiamato da un passaggio del processo di SQL Server Agent. Il pacchetto non viene eseguito all'esterno di SQL Server Agent.

Trascrizione del video

Timestamp video	Audio
00:00	Mi chiamo Carla Sabotta e scrivo documentazione per il prodotto Microsoft SQL Server Integration Services. In questo video vi mostrerò come risolvere i problemi relativi alla mancata esecuzione di un pacchetto di SQL Server Integration Services quando questo viene chiamato da un passaggio del processo di SQL Server Agent. Il pacchetto non viene eseguito all'esterno di SQL Server Agent. Vi parlerò dei metodi consigliati per risolvere questo problema, inclusi la creazione di un account proxy, la modifica dell'impostazione della proprietà ProtectionLevel del pacchetto, il salvataggio dei dati sensibili in un file di configurazione del pacchetto e l'archiviazione di un pacchetto nel database msdb di SQL Server. Come potete notare, questo processo non è stato in grado di eseguire il pacchetto di Integration Services. Quando chiamate un pacchetto da un passaggio del processo di SQL Server Agent e il pacchetto non viene eseguito, sussiste una delle condizioni seguenti: L'account utente che esegue il pacchetto come passaggio del processo è diverso dall'autore originale del pacchetto. - oppure - L'account utente non dispone delle autorizzazioni necessarie per stabilire connessioni o accedere a risorse esterne al pacchetto. Quando l'account utente che chiama il pacchetto dal passaggio di processo è diverso all'autore originale del pacchetto, il livello di protezione del pacchetto potrebbe impedirne l'esecuzione. Questo accade perché l'account utente non è in grado di decrittografare il pacchetto o i suoi dati sensibili oppure non è in grado di fornire i dati sensibili mancanti nel pacchetto. Esempi di dati sensibili sono la parte della password di una stringa di connessione, una variabile contrassegnata come sensibile e così via. Sono disponibili alcuni metodi consigliati per risolvere i problemi relativi alla crittografia e ai dati sensibili.
01:53	Il primo metodo consiste nell'archiviare il pacchetto nel database msdb di SQL Server e impostare il livello di protezione su Controllo di accesso basato sull'archiviazione su server e i ruoli (Rely on server storage and roles for access control). A tale scopo, è necessario utilizzare il servizio Integration Services in SQL Server Management Studio. A questo punto i ruoli del database controllano l'accesso in lettura e scrittura al pacchetto. Dovrete assegnare al ruolo lettura del pacchetto uno dei ruoli a livello di database predefiniti di Integration Services oppure un ruolo a livello di database definito dall'utente. I ruoli a livello di database predefiniti sono db_ssisadmin, db_ssisoperator e db_ssisltduser. In questa dimostrazione assegneremo al pacchetto il ruolo db_ssisadmin. Se assegnate al pacchetto un ruolo a livello di database predefinito, l'account utente che chiama il pacchetto dal passaggio del processo deve essere membro di tale ruolo. Se assegnate al pacchetto un ruolo definito dall'utente, l'account utente deve essere membro di uno dei ruoli a livello di database predefiniti e membro del ruolo definito dall'utente.
03:59	Il secondo metodo consiste nel modificare l'impostazione della proprietà ProtectionLevel del pacchetto in EncryptSensitiveWithPassword in Business Intelligence Development Studio. Potete accedere alla proprietà ProtectionLevel del pacchetto facendo clic in un punto qualsiasi del flusso di controllo del pacchetto e selezionando ProtectionLevel nella finestra Proprietà (Properties). Modificate quindi la riga di comando del passaggio del processo di SQL Server Agent in modo da includere la password per la decrittografia dei dati sensibili. Per aggiungere la password, utilizzate il parametro /Decrypt dell'utilità della riga di comando dtexec. I passaggi del processo di SQL Server Agent utilizzano l'utilità dtexec per eseguire i pacchetti.
05:22	Il terzo metodo per risolvere i problemi relativi alla crittografia e ai dati sensibili consiste nel modificare l'impostazione della proprietà ProtectionLevel del pacchetto in DontSaveSensitive, ancora tramite Business Intelligence Development Studio. Con questa impostazione il pacchetto non viene crittografato e i dati sensibili non vengono salvati con il pacchetto. Per salvare i dati, dovrete quindi utilizzare un file di configurazione del pacchetto. In questa dimostrazione salveremo la parte della password di una stringa di connessione per la gestione connessione DestinationConnectionOLEDB. Quando il passaggio del processo di SQL Server Agent esegue il pacchetto, i dati sensibili vengono caricati dal file di configurazione creato. Accertatevi di archiviare il file in una cartella protetta. Finora abbiamo esaminato i metodi per risolvere i problemi relativi alla crittografia e ai dati sensibili. L'altra condizione che provoca la mancata esecuzione di un pacchetto da parte di un passaggio del processo di un agente riguarda le autorizzazioni dell'account utente. L'account utente non dispone delle autorizzazioni richieste per stabilire connessioni o accedere a risorse esterne al pacchetto.
08:08	Per testare le autorizzazioni dell'account utente, aprite una finestra del prompt dei comandi ed eseguite il comando RunAs. Sostituite dominio\utente (mydomain\myuser con le informazioni di autenticazione archiviate nelle credenziali dell'account. Digiterete la password dell'account quando richiesto. Il metodo consigliato per risolvere il problema relativo alle autorizzazioni consiste nel creare un account proxy di SQL Server Agent con le autorizzazioni necessarie. L'account proxy è anche in grado di decrittografare i dati sensibili nel pacchetto. Non dimenticate, questo metodo potrebbe non funzionare se spostate il pacchetto in un altro computer in cui la proprietà ProtectionLevel del pacchetto è impostata su EncryptSensitiveWithUserKey o EncryptAllWithUserKey.
09:12	Per creare un account proxy dovete essere membri del ruolo del server predefinito sysadmin. In alternativa, dovete essere membri di SQLAgentOperatorRole, SQLAgentReaderRole o SQLAgentUserRole nel database msdb. Per creare un account proxy, potete eseguire una query Transact-SQL oppure utilizzare la finestra di dialogo Nuovo account proxy (New Proxy Account) in SQL Server Management Studio. Noi utilizzeremo la finestra di dialogo Nuovo account proxy (New Proxy Account). Nella pagina Generale (General) specificate il nome e le credenziali del nuovo account proxy. Chiameremo l'account Proxy pacchetto (Package proxy) e selezioneremo credenziali esistenti denominate Utente1 (User1), che contengono le informazioni di autenticazione. Tenete presente che le credenziali selezionate devono permettere a SQL Server Agent di eseguire il processo come account che ha creato il pacchetto o che dispone delle autorizzazioni necessarie. Dovrete anche specificare il sottosistema per cui è abilitato il proxy. Dal momento che il processo esegue un pacchetto, selezioneremo il sottosistema Pacchetto SQL Server Integration Services (SQL Server Integration Services Package). La descrizione del proxy è facoltativa. Nella pagina Entità (Principals) potete aggiungere o rimuovere ruoli per concedere l'accesso all'account proxy. I membri del ruolo del server predefinito sysadmin hanno accesso automatico. Le credenziali Utente1 (User1) che abbiamo specificato per l'account proxy sono elencate nel nodo Credenziali (Credentials) in Esplora oggetti (Object Explorer). Potete creare nuove credenziali eseguendo una query Transact-SQL oppure utilizzando la finestra di dialogo Nuove credenziali (New Credentials). In questo video vi ho mostrato come risolvere i problemi relativi alla mancata esecuzione di un pacchetto quando questo viene chiamato da un passaggio del processo di SQL Server Agent. Nel video abbiamo trattato della creazione di un account proxy, della modifica dell'impostazione della proprietà ProtectionLevel del pacchetto, del salvataggio dei dati sensibili in un file di configurazione del pacchetto e dell'archiviazione di un pacchetto nel database msdb di SQL Server. Grazie dell'attenzione. Speriamo che il video vi sia stato utile e che torniate sul sito Web per guardare altri video su Microsoft SQL Server.