ID do artigo: 918760 - Última revisão: quarta-feira, 30 de setembro de 2009 - Revisão: 2.0

Um pacote do SSIS não é executado quando você chamar o pacote do SSIS a partir de uma etapa de trabalho do SQL Server Agent

Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.

Nesta página

Expandir tudo | Recolher tudo

Sintomas

Quando você chamar um pacote do Microsoft SQL Server 2005 Integration Services (SSIS) a partir de uma etapa de trabalho do SQL Server Agent, o pacote do SSIS não é executado. No entanto, se você não modifique o pacote do SSIS, ele será executado com êxito fora do SQL Server Agent.

Causa

Esse problema ocorre quando uma das seguintes condições for verdadeira:
  • A conta de usuário que é usada para executar o pacote em SQL Server Agent difere do autor original do pacote.
  • A conta de usuário não tem as permissões necessárias para estabelecer conexões ou para acessar recursos fora o pacote do SSIS.
O pacote não pode ser executado nas seguintes situações:
  • O usuário atual não é possível descriptografar os segredos do pacote. Essa situação pode ocorrer se a conta atual ou a conta de execução difere do autor original do pacote e configuração da propriedade ProtectionLevel do pacote não permite que o usuário atual descriptografar segredos no pacote.
  • Uma conexão do SQL Server que usa segurança integrada falha porque o usuário atual não tem as permissões necessárias.
  • Acesso ao arquivo falhará porque o usuário atual não tem as permissões necessárias para gravar o compartilhamento de arquivo que acessa o Gerenciador de conexão. Por exemplo, essa situação pode ocorrer com provedores de log de texto que não use um logon e uma senha. Este cenário também pode ocorrer com qualquer tarefa que depende do Gerenciador de conexão do arquivo, como uma tarefa de sistema de arquivo SSIS.
  • Uma configuração de pacote do SSIS baseadas no registro usa as chaves de registro HKEY_CURRENT_USER. As chaves de registro HKEY_CURRENT_USER são específicas do usuário.
  • Uma tarefa ou um Gerenciador de conexões requer que a conta de usuário atual tenha as permissões corretas.

Resolução

Para resolver esse problema, use um dos seguintes métodos. O método mais apropriado depende do ambiente e o motivo que o pacote falhou.

Método 1: Usar uma conta de proxy do SQL Server Agent

Crie uma conta do proxy SQL Server Agent. Essa conta proxy deve usar uma credencial que permite executar o trabalho como a conta que criou o pacote ou como uma conta que tenha as permissões necessárias do SQL Server Agent.

Esse método funciona para descriptografar os segredos e satisfaça os requisitos de chaves por usuário. No entanto, esse método pode ter limitado êxito porque as chaves de usuário de pacote do SSIS envolvem o usuário atual e o computador atual. Portanto, se você mover o pacote para outro computador, esse método pode ainda falhar, mesmo se a etapa de trabalho usa a conta proxy correto.

Método 2: Define a propriedade ProtectionLevel de pacote do SSIS para ServerStorage

Altere a propriedade do pacote do SSIS ProtectionLevel para ServerStorage. Essa configuração armazena o pacote em um banco de dados do SQL Server e permite o controle de acesso através de funções de banco de dados do SQL Server.

Método 3: Define a propriedade ProtectionLevel de pacote do SSIS para EncryptSensitiveWithPassword

Altere a propriedade do pacote do SSIS ProtectionLevel para EncryptSensitiveWithPassword. Essa configuração usa uma senha para criptografia. Em seguida, você pode modificar a linha de comando do SQL Server Agent trabalho etapa a inclusão dessa senha.

Método 4: Arquivos de configuração usar SSIS Package

Usar arquivos de configuração do pacote do SSIS para armazenar informações confidenciais e, em seguida, armazene esses arquivos de configuração em uma pasta protegida. Em seguida, você pode alterar a propriedade ProtectionLevel para DontSaveSensitive para que o pacote não está criptografado e não tenta salvar segredos para o pacote. Quando você executar o pacote do SSIS, as informações necessárias são carregadas do arquivo de configuração. Certifique-se de que os arquivos de configuração estão adequadamente protegidos se eles contiverem informações confidenciais.

Método 5: Criar um modelo de pacote

Para uma resolução de longo prazo, crie um modelo pacote que usa um nível de proteção que difere da configuração padrão. Esse problema não ocorrerá no futuro pacotes.

Situação

Esse comportamento é por design.

Mais Informações

Etapas para reproduzir o problema

  1. Faça logon como um usuário que não faz parte do grupo SQLServer2005SQLAgentUser. Por exemplo, você pode criar um usuário local.
  2. Criar um pacote do SSIS e, em seguida, adicione uma tarefa ExecuteSQL. Use um Gerenciador de conexão OLEDB no arquivo msdb local usando a seguinte seqüência de caracteres: ? autenticação do Windows ?-SQLSourceType: "Entrada direta" - SQLStatement: "sp_who"
  3. Execute o pacote para certificar-se de que ele executa com êxito.
  4. Observe que a propriedade ProtectionLevel é definida como EncryptSensitiveWithPassword.
  5. Crie um trabalho do SQL Server Agent e uma etapa de trabalho. Na lista Executar como , clique em Serviço do SQL Server Agent para executar a etapa de trabalho.
O texto no histórico do trabalho do SQL Server Agent exibe informações que se assemelha ao seguinte:

Executado como usuário: DOMÍNIO\nome_de_usuário. Falha na execução da pacote. A etapa falhou.

Descriptografar segredos de pacote

A configuração padrão para o pacote do SSIS propriedade ProtectionLevel é EncryptSensitiveWithUserKey. Quando o pacote é salvo, o SSIS criptografa apenas as partes do pacote que contêm propriedades marcadas como "confidenciais," como senhas, nomes de usuário e seqüências de caracteres de conexão. Portanto, quando o pacote é recarregado, o usuário atual deve atender aos requisitos criptografia para as propriedades confidenciais sejam descriptografados. No entanto, o usuário atual não tem que satisfazer os requisitos de criptografia para carregar o pacote. Quando você executa o pacote através de uma etapa de trabalho do SQL Server Agent, a conta padrão é a conta serviço do SQL Server Agent. Essa conta padrão provavelmente é um usuário diferente o autor do pacote. Portanto, a etapa de trabalho do SQL Server Agent pode carregar e iniciar executar a etapa de trabalho, mas o pacote falha porque ele não é possível completar uma conexão. Por exemplo, o pacote não pode concluir uma conexão de banco de dados OLE ou uma conexão FTP. O pacote falha porque ele não pode descriptografar as credenciais que ele deve ter para se conectar.

importante Considere o processo de desenvolvimento e o ambiente para determinar quais contas são necessários e usadas em cada computador. A configuração EncryptSensitiveWithUserKey da propriedade ProtectionLevel é uma configuração eficiente. Essa configuração não deve ser descontada porque faz complicações de implantação inicialmente. Você pode criptografar os pacotes quando estiver conectado à conta apropriada. Você também pode usar o utilitário de linha de comando do SSIS Dtutil.exe para alterar os níveis de proteção, usando um arquivo .cmd e o subsistema de comando do SQL Server Agent. Por exemplo, siga estas etapas. Como você pode usar o utilitário Dtutil.exe em arquivos em lotes e loops, você pode seguir estas etapas para vários pacotes ao mesmo tempo.
  1. Modificar o pacote que você deseja criptografar usando uma senha.
  2. Use o utilitário Dtutil.exe através de uma etapa de trabalho do SQL Server Agent Brazilian OS (cmd Exec) para alterar a propriedade ProtectionLevel para EncryptSensitiveWithUserKey. Este processo envolve descriptografar o pacote usando a senha e, em seguida, re-encrypting o pacote. A chave de usuário que é usada para criptografar o pacote é a etapa de trabalho do SQL Server Agent configurando na lista Executar como .

    Observação Porque a chave inclui o nome de usuário e o nome do computador, o efeito de mover os pacotes para outro computador pode ser limitado.

Certifique-se de que você tenha erro informações detalhadas sobre a falha de pacote SSIS

Em vez de confiar nos detalhes limitados no histórico do trabalho do SQL Server Agent, você pode usar o SSIS log para verificar se você tem informações de erro sobre a falha de pacote do SSIS. Você também pode executar o pacote usando o comando de subsistema exec em vez do comando de subsistema do SSIS.

Sobre o log do SSIS

Provedores de log e log do SSIS permitem que você capturar detalhes sobre a execução do pacote e falhas. Por padrão, o pacote não registra as informações. Você deve configurar o pacote para registrar informações. Quando você configura o pacote para registrar informações, você verá informações detalhadas que é semelhante ao seguinte. Nesse caso, você saberá que se trata de um problema de permissões:

OnError, Nome_domínio, DOMAINNAME\USERNAME, FTP Task,{C73DE41C-D0A6-450A-BB94-DF6D913797A1},{2F0AF5AF-2FFD-4928-88EE-1B58EB431D74},4/28/2006 1:51:59 PM, 28/4/2006 1:51:59 PM,-1073573489, 0 x, não é possível se conectar ao servidor FTP usando o "Gerenciador de conexões FTP".

OnError, Nome_domínio, DOMAINNAME\USERNAME, execute SQL Task,{C6C7286D-57D4-4490-B12D-AC9867AE5762},{F5761A49-F2F9-4575-9E2B-B3D381D6E1F3},4/28/2006 4: 07: 00, 4, 28/2006 16: 07: 00,-1073573396, 0 x, Falha ao adquirir conexão "user01.msdb". Conexão pode não estar configurado corretamente ou você não tenha as permissões corretas nesta conexão.

Sobre o comando de subsistema exec e informações de saída

Usando a abordagem de comando do exec subsistema, você adicionar detalhado console logon opções de linha de comando SSIS para chamar o arquivo executável da linha de comando dtexec.exe SSIS. Além disso, você usar o recurso avançado de trabalho do arquivo de saída. Você também pode usar a opção de Incluir a saída de etapa no histórico para redirecionar as informações de log para um arquivo ou para o histórico de trabalho do SQL Server Agent.

Este é um exemplo de uma linha de comando:

dtexec.exe /FILE 
"C:\_work\SSISPackages\ProtectionLevelTest\ProtectionLevelTest\AgentTesting.dtsx" /MAXCONCURRENT " -1 
" /CHECKPOINTING OFF  /REPORTING V  /CONSOLELOG NCOSGXMT


O log /console retorna detalhes semelhantes aos seguintes:

Error: 2006-04-27 18:13:34.76
   Code: 0xC0202009
   Source: AgentTesting Connection manager "(local).msdb"
   Description: An OLE DB error has occurred. Error code: 0x80040E4D.
An OLE DB record is available.  Source: "Microsoft SQL Native Client"  Hresult: 0x80040E4D  Description: "Login failed for user 'DOMAINNAME\username'.".
End Error


Error: 2006-04-28 13:51:59.19
   Code: 0xC0016016
   Source:  
   Description: Failed to decrypt protected XML node "DTS:Property" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.
End Error


Log:
     Name: OnError
     Computer: COMPUTERNAME
     Operator: DOMAINNAME\username
     Source Name: Execute SQL Task
     Source GUID: {C6C7286D-57D4-4490-B12D-AC9867AE5762}
     Execution GUID: {7AFE3D9E-5F73-42F0-86FE-5EFE264119C8}
     Message: Failed to acquire connection "(local).msdb". Connection may not be configured correctly or you may not have the right permissions on this connection.
     Start Time: 2006-04-27 18:13:34
     End Time: 2006-04-27 18:13:34
End Log

Referências

Para obter mais informações sobre um problema semelhante, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
904800  (http://support.microsoft.com/kb/904800/ ) Você recebe uma mensagem de erro "Erro ao carregar" quando tenta executar um pacote do SQL Server 2005 Integration Services no SQL Server 2005
Para obter mais informações sobre como usar o utilitário Dtutil.exe em operações em lotes, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
906562  (http://support.microsoft.com/kb/906562/ ) Como usar o utilitário dtutil (Dtutil.exe) para definir o nível de proteção de um lote de pacotes SSIS (SQL Server Integration Services) no SQL Server 2005
Para obter mais informações sobre como criar modelos de pacote, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
908018  (http://support.microsoft.com/kb/908018/ ) Como criar um modelo de pacote no SQL Server Business Intelligence Development Studio


Para obter mais informações sobre segurança de pacote do SSIS e a propriedade ProtectionLevel , consulte o tópico "Security Considerations para Integration Services" nos manuais online do SQL Server 2005.

Infelizmente, os usuários não têm conhecimento que as configurações de etapa de trabalho de agente padrão coloca nesse estado. Para obter mais informações sobre proxies do SQL Server Agent e o SSIS, consulte os seguintes tópicos nos manuais online do SQL Server 2005:
  • Agendamento de execução do pacote no SQL Server Agent
  • Criando proxies do SQL Server Agent

A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2008 Service Pack 1
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2005 Service Pack 3
  • Microsoft SQL Server 2005 Service Pack 2
  • Microsoft SQL Server 2005 Service Pack 1
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems
Palavras-chave: 
kbmt kbprb kbsql2005ssis kbsql2005setup kbexpertiseinter kbexpertiseadvanced kbtshoot KB918760 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 918760  (http://support.microsoft.com/kb/918760/en-us/ )