Solução de problemas: execução de pacotes SSIS usando o SQL Server Agent (vídeo do SQL Server)
Aplica-se a: Microsoft SQL Server Integration Services |
Autores: Carla Sabotta, Microsoft Corporation |
Duração: 00:12:12 Tamanho: 9,50 MB Tipo: WMV |
Resumo do vídeo
Este vídeo demonstra como resolver problemas de um pacote do SQL Server Integration Services que não é executado quando você o chama a partir de uma etapa de trabalho do SQL Server Agent. O pacote é executado com êxito fora do SQL Server Agent.
Transcrição do vídeo
| Marcação de tempo do vídeo | Áudio |
|---|---|
00:00 |
Olá, meu nome é Carla Sabotta. Eu redijo a documentação do produto Microsoft SQL Server Integration Services. Neste vídeo, vou mostrar como resolver problemas de um pacote do SQL Server Integration Services que não é executado quando você o chama a partir de uma etapa de trabalho do SQL Server Agent. O pacote é executado com êxito fora do SQL Server Agent. Você aprenderá os métodos recomendados para resolver esse problema, além de criar uma conta proxy, modificar as configurações da propriedade ProtectionLevel do pacote, salvar dados confidenciais em um arquivo de configuração do pacote e armazenar um pacote no banco de dados msdb do SQL Server. Como você pode ver, este trabalho não conseguiu executar o pacote do Integration Services. Quando você chama um pacote a partir de uma etapa de trabalho do SQL Server Agent e o pacote não é executado, uma das seguintes condições é verdadeira:
Quando a conta de usuário que chama o pacote a partir da etapa de trabalho não é o autor original do pacote, o nível de proteção do pacote pode impedir que ele seja executado. Isso ocorre porque a conta de usuário não descriptografa o pacote ou os dados confidenciais do pacote, ou a conta de usuário não pode fornecer dados confidenciais que não estejam no pacote. Exemplos de dados confidenciais são a parte da senha de uma cadeia de conexão, uma variável marcada como confidencial, etc. Existem alguns métodos recomendados para a solução de problemas relacionados a criptografia e dados confidenciais. |
01:53 |
O primeiro método é armazenar o pacote no banco de dados msdb do SQL Server e definir o nível de proteção como Depender de armazenamento e funções do servidor para controlar acesso (Rely on server storage and roles for access control). Para isso, você poderá usar o serviço Integration Services no SQL Server Management Studio. As funções de banco de dados agora controlam o acesso de leitura e gravação ao pacote. É necessário atribuir à função de Leitor do pacote uma das funções fixas no nível de banco de dados do Integration Services ou uma função no nível de banco de dados definida pelo usuário. As funções fixas no nível de banco de dados são db_ssisadmin, db_ssisoperator e db_ssisltduser. Nesta demonstração, iremos atribuir db_ssisadmin ao pacote. Se você atribuir uma função fixa no nível de banco de dados ao pacote, a conta de usuário que chamar o pacote a partir da etapa de trabalho deverá ser membro dessa função. Se você atribuir uma função definida pelo usuário ao pacote, a conta de usuário deverá ser membro de uma das funções fixas no nível de banco de dados e membro da função definida pelo usuário. |
03:59 |
O segundo método é alterar a configuração da propriedade ProtectionLevel do pacote para EncryptSensitiveWithPassword, no Business Intelligence Development Studio. Você acessa a propriedade ProtectionLevel do pacote clicando em qualquer lugar no fluxo de controle do pacote e, em seguida, selecionando ProtectionLevel na janela Propriedades. Em seguida, você modifica a linha de comando da etapa de trabalho do SQL Server Agent para incluir a senha que descriptografa os dados confidenciais. Para adicionar a senha, use o parâmetro /Decrypt do utilitário de prompt de comando dtexec. As etapas de trabalho do SQL Server Agent usam o utilitário dtexec para executar pacotes. |
05:22 |
O terceiro método de resolução de problemas de criptografia e dados confidenciais é alterar a configuração da propriedade ProtectionLevel do pacote para DontSaveSensitive, novamente utilizando o Business Intelligence Development Studio. Com essa configuração de propriedade, o pacote não é criptografado e os dados confidenciais não são salvos com o pacote. Portanto, você usa um arquivo de configuração do pacote para salvar os dados. Nesta demonstração, salvaremos a parte da senha de uma cadeia de conexão para o gerenciador de conexões DestinationConnectionOLEDB. Quando a etapa de trabalho do SQL Server Agent executar o pacote, os dados confidenciais serão carregados do arquivo de configuração que foi criado. Assegure-se de armazenar o arquivo em uma pasta protegida. Até aqui, examinamos métodos para resolver problemas relacionados a criptografia e dados confidenciais. A outra condição que resulta de uma etapa de trabalho do agente que não consegue executar um pacote se refere a permissões de conta de usuário. A conta de usuário não tem as permissões necessárias para fazer conexões ou acessar recursos fora do pacote. |
08:08 |
Para testar as permissões da conta de usuário, abra uma janela de prompt de comando e execute o comando RunAs. Substitua mydomain\myuser pelas informações de autenticação armazenadas na credencial da conta. Digite a senha da conta de serviço quando for solicitado. O método recomendado para solução do problema relacionado a permissões é criar uma conta proxy do SQL Server Agent que tenha as permissões necessárias. A conta proxy também descriptografa dados confidenciais no pacote. Lembre-se de que esse método poderá falhar se você mover o pacote para outro computador, e se a propriedade ProtectionLevel do pacote estiver definida como EncryptSensitiveWithUserKey ou EncryptAllWithUserKey. |
09:12 |
Para criar uma conta proxy, você deve ser membro da função de servidor fixa sysadmin. Ou deve ser um membro de SQLAgentOperatorRole, SQLAgentReaderRole ou SQLAgentUserRole no banco de dados msdb. Você cria uma conta proxy executando uma consulta Transact-SQL ou usando a caixa de diálogo Nova Conta Proxy (New Proxy Account) no SQL Server Management Studio. Nós usaremos a caixa de diálogo Nova Conta Proxy (New Proxy Account). Na página Geral (General), especifique o nome e a credencial da nova conta proxy. Chamaremos a conta de Proxy do pacote e selecionaremos uma credencial existente, User1, que contém as informações de autenticação. Lembre-se de que a credencial selecionada deve permitir que o SQL Server Agent execute o trabalho como a conta que criou o pacote ou como uma conta que tem as permissões necessárias. Você também precisa especificar o subsistema para o qual o proxy está habilitado. Como o trabalho está executando um pacote, selecionaremos o subsistema Pacote do SQL Server Integration Services (SQL Server Integration Services Package). A descrição do proxy é opcional. Na página Entidades (Principals), você pode adicionar ou remover funções para conceder acesso à conta proxy. Os membros da função de servidor fixa sysadmin têm acesso automático. A credencial User1 que especificamos para a conta proxy é listada no nó Credenciais (Credentials) no Pesquisador de Objetos. Você pode criar uma nova credencial executando uma consulta Transact-SQL ou usando a caixa de diálogo Novas Credenciais (New Credentials). Este vídeo demonstrou como resolver problemas de um pacote que não é executado quando chamado a partir de uma etapa de trabalho do SQL Server Agent. Abordamos aqui como criar uma conta proxy, modificar as configurações da propriedade ProtectionLevel do pacote, salvar dados confidenciais em um arquivo de configuração do pacote e armazenar um pacote no banco de dados msdb do SQL Server. Obrigada por assistir a este vídeo, esperamos que ele tenha sido útil. Vamos agora retornar ao site para assistir a outros vídeos do Microsoft SQL Server. |