Temos um fornecedor terceirizado tentando integrar 2 aplicativos diferentes em que ambos os bancos de dados residem em nossa instância do SQL Server com mais de 150 outros bancos de dados e eles desejam criar um trabalho MSDB para "sincronizar" os 2 aplicativos diferentes a cada 5 minutos (no início, eles queria executá-lo a cada minuto).
Meu palpite inicial é que eles deveriam fazer isso de alguma forma na camada do aplicativo com um trabalho agendado do Windows, ou talvez até mesmo um gatilho temido (ao qual normalmente recorremos em situações como essa).
Eu prefiro manter os trabalhos MSDB reservados para tarefas DBA tanto quanto possível para reduzir a confusão lá, e também me deparei com consultas lentas do MSDB ao visualizar históricos de trabalhos com trabalhos superativos como este (que também afogam e eliminam históricos de trabalhos importantes de coisas mais importantes, como históricos de backup). Mas, novamente, talvez minhas preferências estejam erradas e eu precise abrir espaço para a camada de aplicativos no MSDB, arregaçar as mangas e corrigir problemas de históricos de trabalho que demoram uma eternidade para carregar quando preciso reter muito mais entradas de histórico para capturar o coisas importantes como backups (ou limpar as entradas de trabalho hiperativas).
Outro problema que tenho é que agora preciso dar a este fornecedor direitos de "sysadmin" em vez de apenas direitos de "dbo" apenas em seus bancos de dados quando eles executam suas atualizações por meio de sua GUI e espero que eles não explodam a instância onde minha missão crítica Os bancos de dados são (uma das desvantagens da consolidação).
Acho que posso colocá-los em outra instância "isolada" onde colocamos todos os fornecedores que não jogam bem, mas então precisamos reconfigurar os aplicativos para apontar para a nova instância SQL ( suspiro infelizmente não é trivial neste caso).
O fornecedor já rejeitou minhas preocupações falando sobre como os gatilhos são ruins. Então, eu "pesquisei" um pouco sobre isso e não encontrei nada. Alguém viu algum link por aí com "aparência autoritária" que isso é uma má ideia e eu posso encaminhá-lo para ele? Ou devo abraçar a abordagem deles?
Acho que nunca postei em um fórum de sql antes de pedir ajuda, então espero que minha pergunta esteja devidamente enquadrada.
EDIT: Estamos executando o SQL Server 2008 Enterprise R2 x64 SP1 (obrigado por apontar que esqueci de mencionar a versão!). Hmmm, esperamos que eles não precisem alterar seus scripts de atualização do MSDB quando formos para uma versão mais recente.
Obrigado pelo seu tempo! Rico
IMO, seu fornecedor está realmente no caminho certo.
Um trabalho de camada de aplicativo exigiria que ele refizesse vários recursos do SQL Agent prontos para uso (por exemplo, lógica para não executar um trabalho que já está em execução, criar uma solução de armazenamento de segurança e credenciais, integrar os resultados do trabalho com relatório de erros e rastreamento de resultados em SQL etc etc etc etc). E, o mais importante, forneça uma solução de backup/HA/DC para o agendamento. Você não deseja que sua história de recuperação de desastres seja 'e depois de terminar de recuperar o servidor em espera, crie essas 50 tarefas do agendador do NT'. Portanto, ele está certo em resistir ao uso do agendador do sistema, pois ele não tem nada dos recursos e capacidades que o Agente tem.
Ele está ainda mais certo em recuar contra os gatilhos. A substituição de um trabalho periódico por um gatilho síncrono aumenta a latência da solicitação, aumenta a coesão e o acoplamento (pense em alterações de esquema...), aumenta o risco de tempo de inatividade devido a problemas de sincronização (erro de gatilho->erro de aplicativo vs. erro de trabalho->corrigir e tentar novamente mais tarde) , aumenta drasticamente os problemas de impasse (devido a atualizações cruzadas entre rastreado/rastreado) e tem muito mais problemas.
A solução mais fácil é, de fato, um trabalho de Agente e
msdbnão é de forma alguma reservada para DBAs. Uma solução mais sofisticada seria usar timers de conversação e ativação interna , o que teria algumas vantagens sobre os trabalhos do agente, principalmente devido à contenção (tudo está dentro do banco de dados do aplicativo, pense em cenários de failover de espelhamento), mas posso entender totalmente se o seu fornecedor é relutam em experimentar algo que requer um know-how muito específico. BTW, espero que você não queira dizer um trabalho a cada 5 minutos por banco de dados .Quanto às permissões de administrador de sistema: o nome do jogo é assinatura de código . Você pode dar qualquer permissão para procedimentos específicos, inspecionados e validados por você, assinando-os com seu certificado privado.
Minha preferência pessoal seria usar gatilhos para lidar com pelo menos parte da sincronização. Não me importo particularmente com a sincronização de pesquisa agendada, pois você precisa lidar com possíveis conflitos, dados obsoletos, impacto no desempenho do trabalho repetido etc. é para mitigar conflitos e desatualização, e o imediatismo de um gatilho resolveria isso.
Se tudo estiver acontecendo no mesmo servidor, você provavelmente não terá problema em colocar o código de sincronização nos gatilhos ou fazer com que os gatilhos chamem um procedimento armazenado que sincroniza cada registro afetado. Se a sincronização abranger servidores ou se você quiser ter certeza de que ter um banco de dados offline não impedirá que o outro banco de dados seja utilizável, procure usar o Service Broker para lidar com atualizações assíncronas. Eu fiz isso para sincronizar os números de entrada de vendas com os dados do CRM entre dois servidores diferentes, enquanto permitia que qualquer um dos servidores ficasse offline sem afetar o outro aplicativo. Depois de voltar, o Service Broker entrega as mensagens e atualiza os dados no servidor remoto.
E realmente não há nada inerentemente ruim sobre gatilhos, mas como a maioria dos aspectos do T-SQL, é muito possível escrever um código com desempenho horrível. Escrevi um artigo sobre as armadilhas comuns dos gatilhos, se isso ajudar.
Escrevendo gatilhos bem comportados