Muitas vezes vejo "problemas" que envolvem requisitos para o SQL Server realizar "trabalho sujo" como:
- No meu gatilho preciso copiar um arquivo de/para a rede
- Meu procedimento armazenado precisa enviar um arquivo por FTP
- Depois que o backup terminar, preciso do SQL Server para compactá-lo, fazer uma cópia e arquivá-lo
- Quando um cliente é adicionado, quero criar um novo banco de dados e fazer várias coisas no Active Directory
- Meu trabalho do SQL Server Agent precisa verificar um diretório em busca de arquivos e realizar inserções em massa quando encontrar novos
Isto não é uma lista exaustiva; Eu provavelmente poderia preencher uma página. O ponto é que executar essas tarefas de dentro do SQL Server apresenta obstáculos significativos:
Segurança
Normalmente, para qualquer coisa em que você considere que o SQL Server precise de sistema de arquivos ou outro acesso no nível do sistema operacional, você (a) concederá direitos de carta branca explícitos à conta de serviço do SQL Server (e/ou às contas do SQL Agent/proxy), ou (b) apenas defina as contas de serviço do SQL Server para serem executadas como uma conta de domínio existente que já tenha todos esses direitos. Esta é a solução "fácil" - agora, em vez de conceder acesso individual a essa pasta e a esse compartilhamento e a esse outro recurso, você apenas limpa as mãos porque eles já são administradores de domínio. Em seguida, você habilita as configurações de nível de servidor que estão desabilitadas por padrão, mas estão no seu caminho para realizar uma ou mais das tarefas acima (por exemplo,
xp_cmdshell ). Acho que não preciso explicar o nível de exposição que essas ações podem representar. Ou que tipo de problemas podem acontecer se esta for uma conta de funcionário real e esse funcionário for embora - ou determinar que está descontente antes de ir embora. Caramba. Já vi vários casos em que uma conta comum é usada para todos os SQL Servers. Adivinha o que acontece se/quando você precisar alterar a senha de uma conta de domínio que está sendo usada ativamente por dezenas ou centenas de instâncias do SQL Server? Não importa com que frequência isso acontecerá se você não excluir esse usuário das políticas de redefinição de senha?
Desempenho
Além dos problemas de segurança, sair do servidor de banco de dados pode causar atrasos enquanto o SQL Server depende de algum processo externo sobre o qual não tem controle. A transação do banco de dados realmente precisa esperar que um arquivo seja compactado e copiado, ou que uma transferência de FTP seja concluída ou que seu controlador de domínio de backup responda? Como isso se compõe quando vários usuários estão executando tarefas semelhantes, todos competindo pela mesma largura de banda e/ou cabeças de disco? Além disso, você deve considerar que, uma vez que o SQL Server disse a algum arquivo em lote para fazer algo, a transação contida é revertida, você não pode reverter a ação externa.
A resposta
Bem, geralmente – e sempre há exceções – a resposta é usar processos externos para essas tarefas que realmente são externas ao SQL Server. Use PowerShell, use C#, use arquivos em lote; caramba, use VBScript. Pense em quais dessas tarefas realmente precisam ser tratadas *imediatamente* e enquanto a transação ainda estiver ativa – suspeito que não sejam muitas. Crie uma tabela de filas para eles e grave na tabela de filas dentro da transação (que será revertida se a transação não for bem-sucedida). Em seguida, tenha uma tarefa ou script em segundo plano que consuma linhas da tabela de filas, execute a(s) tarefa(s) associada(s) e exclua ou marque cada linha como concluída. Bônus adicional:o SQL Server Agent não é necessário aqui, portanto, você pode usar qualquer agendador corporativo e a metodologia ainda funciona com o SQL Server Express.
