Estou tentando permitir que um logon inicie um pacote SSIS por meio dos procedimentos armazenados SSISDB internos em vez de fazê-lo por meio do SQL Agent.
O login será conectado por meio de um Airflow DAG em uma caixa Ubuntu, portanto, estamos utilizando o FreeTDS / pyodbc para permitir que ele se autentique como um login do Windows, o que está funcionando bem.
No entanto, acontece o seguinte ao iniciar o pacote:
- O pacote é iniciado usando
[SSISDB].[catalog].[start_execution] @execution_id. Tentei executar de forma síncrona e assíncrona. - Um ID de execução é gerado, juntamente com uma entrada
[SSISDB].[catalog].[executions]com status 5 ("Pendente") - ~1 minuto depois, a execução "conclui" e o ID de execução é apagado de todas as tabelas do SSISDB e não aparece em nenhum dos relatórios integrados.
Mesmo ao adicionar parâmetros exec para criar arquivos de despejo , nenhum é criado durante a execução do pacote.
Problema de bônus: durante o período de ~1 minuto, outros pacotes sendo iniciados do SQL Agent que geralmente funcionam bem geralmente falham com esta mensagem de erro:
A operação falhou porque a execução expirou.
Notas:
- A instalação do SQL Server está no Windows e é SQL Server 2016 Ent.
- Esse processo funciona bem ao usar meu login de autenticação do Windows em uma caixa do Windows.
- A conta do Windows que está sendo usada pelo DAG é a conta de serviço do agente, portanto, tem todas as permissões necessárias.
- Os dois campos SID
[SSISDB].[catalog].[executions]para a execução pendente correspondem aos SIDs de outras execuções de trabalho que estão sendo tratadas pelo SQL Agent para a mesma conta de serviço. - Estamos usando o TDS versão 7.2 e a versão mais recente do FreeTDS.
- Nenhuma diferença ao usar o autocommit True/False
- Nenhum bloqueio visto durante a execução
Estou supondo que o logon está sendo autenticado novamente quando é usado para iniciar o processo SSIS externo, mas espero que haja alguma maneira de fazer isso ainda funcionar.
A chamada via CLR é uma opção indesejável devido à complexidade adicional e às implicações de segurança.
Atualmente, também estou testando o lançamento deles via dtexec via xp_cmdshell (parecendo promissor), mas não está claro para mim como / por que isso funcionaria e usar os procedimentos armazenados não.
As execuções do catálogo SSIS representam o logon conectado, portanto, provavelmente corrija que é um problema de autenticação. A solução fácil é provisionar um SQL Agent Proxy para a identidade em que você deseja executar o pacote e configurar um trabalho de agente para executar o pacote, invocando o trabalho com sp_start_job .
Isso é semelhante, mas mais seguro, do que usar xp_cmdshell para executar o dtexec diretamente ou chamar os procedimentos de execução do pacote do powershell. Em ambos os casos, uma identidade local é usada para executar o pacote.