Ser administrador de banco de dados tem muitas responsabilidades, e saber o que está acontecendo no seu SQL Server é uma delas. Ser proativo e alerta para erros é uma das características que faz de alguém um ótimo DBA. E não estou falando apenas sobre as coisas falharem, que é o que a maioria das pessoas pensa ao ser alertada; você também pode ser alertado sobre problemas de desempenho. No SQL Server, você tem a capacidade de criar Alertas do SQL Server Agent (que chamarei apenas de ‘alertas’ a partir de agora), e isso é facilmente realizado usando a GUI ou o T-SQL.
Configurando alertas do SQL Server Agent
Para usar alertas, você deve ter o Database Mail e um SQL Agent Operator configurados. A maioria das instâncias SQL que encontrei já tem o Database Mail configurado para notificações de falha de trabalho. Se precisar de mais informações sobre como configurar esse recurso, visite o tópico dos Manuais Online, "Configurar o Database Mail".
Uma tarefa menos conhecida é configurar o Operador. Você pode criar o operador usando SSMS ou T-SQL. Dentro do SSMS, expanda SQL Server Agent, clique com o botão direito do mouse em Operador e escolha Novo Operador. Você terá uma nova caixa de diálogo aberta onde você pode dar um nome ao operador e especificar o endereço de e-mail para notificar. Eu prefiro usar um grupo de distribuição para as notificações por email. A maioria das empresas tem mais de uma pessoa responsável pelo ambiente SQL e, se você especificar um grupo de distribuição, toda a equipe poderá ser notificada sobre os alertas. O uso de grupos de distribuição também facilita muito a adição ou remoção de pessoas dos alertas.
Abaixo está uma captura de tela de exemplo da caixa de diálogo Novo Operador:
Prefiro usar o T-SQL para garantir que a criação do Operador faça parte de um modelo de compilação do servidor. O código de exemplo para criar o operador acima é o seguinte:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
Depois de configurar o Database Mail e o Operator, você pode criar os alertas e atribuí-los ao Operator.
Se estiver usando o SSMS, você poderá expandir o SQL Server Agent e, em seguida, Alertas. Por padrão, nenhum alerta é criado. Se você clicar com o botão direito do mouse e escolher Novo Alerta, aparecerá uma tela semelhante à figura abaixo:
Você notará que em Gravidade, existem 25 códigos de gravidade. Assim como parece, a gravidade do nível de erro descreve a importância do erro. A gravidade 10 é informativa, enquanto 19-25 são fatais e você desejará ser notificado quando esses erros surgirem. Se ocorrer um erro de gravidade 23, por exemplo, você provavelmente está corrompido em um de seus bancos de dados. Todos esses erros fatais podem afetar o desempenho do seu servidor, o que, por sua vez, afeta a experiência do cliente.
Há um alerta adicional que você precisa criar, para o erro 825. O erro 825, como Paul Randal descreve em sua postagem no blog, está relacionado a uma operação de E/S que o SQL Server teve que tentar novamente, mas que eventualmente é bem-sucedida (enquanto os erros 823 e 824 indicam que uma operação de repetição de E/S foi repetida e falhou). É importante conhecer o erro 825 porque está alertando você sobre problemas de E/S que podem se tornar fatais no futuro. Qualquer tentativa de repetição é ruim, você não deve esperar até que uma operação de E/S falhe para ser notificada. Se você começar a receber mensagens de erro 825, precisará entrar em contato imediatamente com suas equipes de armazenamento e hardware.
Você pode criar cada um dos Alertas especificando o nome e selecionando a gravidade. Para o Erro 825, você selecionaria Erro e digitaria o número. Assim como com o Operador, prefiro usar T-SQL. Se eu puder criar scripts de um processo facilmente, será muito mais fácil reutilizar e incluir como parte de uma compilação de servidor.
Abaixo, você encontrará o script que usei na minha estação de trabalho do SQL Server 2014 Developer. Esse script cria cada um dos alertas e adiciona uma notificação para o alerta ao Operator SQL_Alerts.
EXEC msdb.dbo.sp_add_alert @name = N'Severity 19 Error', @message_id = 0, @severity = 19, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 19 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 20 Error', @message_id = 0, @severity = 20, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 20 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name=N'Severity 21 Error', @message_id = 0, @severity = 21, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 21 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 22 Error', @message_id = 0, @severity = 22, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 22 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 23 Error', @message_id = 0, @severity = 23, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 23 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 24 Error', @message_id = 0, @severity = 24, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 24 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 25 Error', @message_id = 0, @severity = 25, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 25 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Error 825', @message_id = 825, @severity = 0, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Error 825', @operator_name = N'SQL_Alerts', @notification_method = 1;
Se você acompanhou, você teria configurado o correio do banco de dados, criado um Operador para enviar um e-mail a você ou a um grupo de distribuição sobre possíveis erros e Alertas do SQL Server Agent configurados para Gravidade 19 – 25 e erro 825.
Isso é ótimo. Sempre que um desses alertas for acionado, um e-mail será enviado para sua equipe. Além dos alertas de eventos, os alertas podem ser configurados para uma condição de desempenho, conforme mencionei na introdução. Por exemplo, se o uso de memória exceder um limite definido, um alerta poderá ser acionado. Eu o encorajo a explorar os vários alertas de desempenho e criar aqueles dos quais sua organização pode se beneficiar. Para localizar os alertas de condição de desempenho do SQL Server, na nova caixa de diálogo de alerta, clique na caixa suspensa para Tipo. Lá você verá o alerta de condição de desempenho do SQL Server listado. Depois de escolher essa opção, você pode navegar pelos tipos de objetos nos quais pode configurar um alerta de condição de desempenho.
Embora tenhamos atribuído um operador à resposta de alerta, você também pode configurar o alerta para executar um trabalho do SQL Agent. Embora isso lhe dê alguma flexibilidade para ter uma tarefa de resposta a eventos, não oferece a capacidade de ter alertas condicionais fáceis.
Usando o SQL Sentry para alertas avançados
Para alertas mais avançados, você precisa de uma ferramenta melhor. É aqui que o SQL Sentry pode ajudar. Um dos meus recursos favoritos de alerta do SQL Sentry é a capacidade de criar condições personalizadas para alertar ou agir quando algo mudou no ambiente. Por exemplo, se alguém alterou o valor mínimo ou máximo de memória, modificou o maxdop ou o limite de custo para paralelismo, você pode receber um alerta ou até mesmo iniciar um processo. Esse recurso foi introduzido no SQL Sentry v8, e Greg Gonzalez (blog | @SQLsensei) escreveu sobre isso aqui:"SQL Sentry v8:Intelligent Alerting Redefined".
Com esse recurso, você também pode criar condições personalizadas para diferentes bancos de dados em um único alerta. Se você tentasse isso usando alertas do SQL Agent, teria que criar alertas diferentes por banco de dados.
Outro ótimo recurso de alerta é a capacidade de criar diferentes horários de alerta. Muitas organizações têm equipes que são responsáveis durante diferentes partes do dia. Alguns podem ter os DBA's de produção responsáveis durante o dia com um Centro de Operações de Rede cobrindo o turno da noite, depois uma pessoa de plantão nos finais de semana. Não seria ótimo poder personalizar um cronograma de alertas para notificar as equipes apropriadas durante o horário de responsabilidade?
Você pode criar janelas de alerta (como em uma janela de tempo) e vinculá-las a diferentes alertas ou grupos. Isso permite que diferentes alertas estejam ativos em horários diferentes e que diferentes grupos sejam notificados em horários diferentes. Isso é muito legal, pois permite que seus alertas sigam um cronograma de suporte para que as pessoas corretas sejam notificadas. Scott Fallen detalha esse recurso em uma postagem no blog, "Alertando em uma programação de chamada com o SQL Sentry", orientando você na criação de alertas para várias equipes de plantão.
Outro recurso de alerta do Performance Advisor e do Event Manager é a capacidade de configurar outras respostas, como executar um processo do Windows, registrar o evento em um banco de dados ou log de erros, enviar uma interceptação SNMP para outra ferramenta de monitoramento, como SCOM, ou até mesmo matar um processo . Suas opções são quase ilimitadas quanto ao que você pode ter predefinido para acontecer quando um determinado evento ocorrer. Alertas do SQL Agent não são tão personalizáveis.
Resumo
O importante desta postagem é que você absolutamente precisa estar alerta para erros e condições de desempenho. Se você não possui uma ferramenta como o SQL Sentry, utilizar os Alertas do SQL Agent ainda é um ótimo começo.
Nos próximos posts, vou me aprofundar em alguns desses alertas que afetam o desempenho e discutir quais ações você precisaria tomar quando eles surgirem.
