Como posso monitorar as etapas do trabalho com falha no servidor SQL?

Question

Temos dois servidores MS SQL (um 2000 e um 2005) que executam vários jobs em vários horários durante o dia e a noite. Essas tarefas têm várias etapas que extraem dados de um banco de dados Informix (nosso sistema de negócios) e atualizam tabelas para uso por vários sistemas de relatórios e produção.

Tivemos uma falha dessas importações no final de semana, o que resultou em muitos sistemas de relatórios fornecendo dados errados.

Devido a restrições de segurança, não podemos habilitar o envio de e-mails dos servidores. Então, como podemos monitorar esses trabalhos sem precisar verificar constantemente o status do trabalho no Enterprise Manager ou no MS SQL Studio? É possível executar uma consulta nos servidores e encontrar o status de várias tarefas?

    

Answer 1

Existem várias maneiras diferentes de monitorar a saída de tarefas do servidor sql.

Opção 1: ferramenta de monitoramento, como Sitesope, MOM / SCOM ou personalizada Para a maioria das instâncias de produção, você deseja ter uma ferramenta de monitoramento corporativo que procura por erros relacionados ao SO e SQL. Geralmente, você define suas tarefas do Agente Sql para gravar no log de eventos do Windows quando elas falham, e sua ferramenta de monitoramento lê com freqüência o log de eventos do Windows e o alerta com base nas condições definidas por você. Você pode adquirir um sistema de monitoramento como o SiteScope ou criar sua própria ferramenta para procurar esses erros. Você também pode usar uma ferramenta como o Logparser para ler esses registros.

Eu menciono essa opção primeiro, porque se o seu sistema de relatórios é crítico, você provavelmente quer investir em um sistema de monitoramento confiável a longo prazo. Curto prazo, você poderia fazer alguns scripts personalizados se quisesse usar a rota de Log do Windows.

Opção 2: consultando o MSDB Todo o histórico de tarefas do sql é armazenado no banco de dados MSDB, e você pode realmente consultá-lo. Você pode fazer isso tanto de janelas de consulta quanto de uma ferramenta personalizada - por exemplo, você pode criar um script powershell que se conecte periodicamente a cada um dos seus servidores e consulte o banco de dados msdb para determinadas condições e alertas.

Eu escrevi algumas entradas de blog que possuem scripts de amostra para consultar o histórico de tarefas do sql. Nenhum deles faz exatamente o que você está pedindo, mas eles o ajudarão a trabalhar com o modo como as datas são armazenadas no MSDB, o que pode ser um pouco complicado, pois não são armazenados em campos de data e hora: link

Espero que isso ajude!

    

Answer 2

Toda vez que menciono isso, sou gritado, mas vou mencioná-lo de qualquer maneira porque funciona para mim.

Praticamente tudo que você faz como um trabalho SQL, você pode fazer a partir de um arquivo em lote usando osql para executar os comandos SQL apropriados. A vantagem de um arquivo em lote é que você tem grande flexibilidade em como analisar os resultados e enviar notificações se houver algum erro. Especialmente se você usar o Powershell. Basta executar o arquivo em lote do agendador do Windows.

A crítica usual é que esta é uma maneira não padrão de fazer as coisas, e eu acho que é. No entanto, tenho mais de cem servidores espalhados pelo Noroeste do Reino Unido e usando arquivos em lote (e alguns VBScript) para executar backup de banco de dados e tarefas de manutenção e analisar os resultados é a melhor maneira que encontrei para tornar as coisas manejáveis. p>

JR

    

Answer 3

Se seu aplicativo de monitoramento puder executar uma declaração SQL:

Você pode executar sp_help_job e soltar os resultados em uma tabela, em seguida, procurar por trabalhos que tenham um last_run_outcome de 0. Se houver algum aplicativo de monitoramento, envie um email.

Ou melhor ainda, informe ao seu gerenciamento que a restrição de que o SQL Server não pode enviar e-mails está prejudicando o monitoramento proativo do SQL Server, pois o SQL Server não pode ser usado nos recursos mais completos, alertando os DBAs onde é uma falha no trabalho.

Suponho que você use algum tipo de sistema de correio de classe Enterprise (Exchange, Lotus, etc). Configure o SQL Server para enviar e-mails via SMTP para o sistema de e-mail e configure o sistema de e-mail para que o SQL Server possa enviar apenas por e-mail os DBAs. Dessa forma, não deve haver nenhuma preocupação sobre o SQL Server enviando magicamente emails para pessoas que não deveriam obtê-las.

Qual é a lógica por trás de não permitir que os SQL Servers enviem e-mails de qualquer maneira?