Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

SQL Server: Sessão executando há muito tempo com o comando sp_readrequest (DatabaseMail)

Visualizações: 3.182 views
Tempo de Leitura: 3 minutos

Olá pessoal,
Boa tarde!

Neste post, vou compartilhar com vocês um aprendizado que tive essa semana. Na empresa onde eu trabalho, foi atualizada recentemente a versão do RedGate SQL Monitor e com isso, foram criados vários alertas para monitoramento de instâncias.

Um desses monitoramentos, é o de long running queries, que identifica sessões que estão executando uma instrução há mais de X minutos. Configuramos esse tempo em 3 minutos, então qualquer sessão que execute um comando que ultrapasse esse tempo de execução na produção, será alertada a equipe de DBA analisar.

O problema é que identificamos que existia uma sessão que sempre era alertada e acabava disparando várias a várias vezes esse alerta, todos os dias, gerando SPAM no nosso e-mail e fazendo com que esse alerta perca a sua importância.

Analisando o alerta, podemos observar que essa sessão era do Database Mail, um utilitário do próprio SQL Server, que executava o comando sp_readrequest, conforme o alerta nos mostra abaixo:

why-a-session-with-sp_readrequest-takes-so-long-to-execute

A stored procedure sp_readrequest é uma procedure de sistema, que basicamente lê as solicitações de mensagens da fila e retorna seu conteúdo. Esse processo fica ativo na instância por um tempo mínimo, determinado pelo parâmetro “DatabaseMailExeMinimumLifeTime”, cujo tempo padrão é de 600 segundos. Ou seja, sempre que esse processo for iniciado (e ele é iniciado constantemente), ele ficará executando por no mínimo, 600 segundos, e por isso, o alerta sempre era disparado.

Para resolver esse problema, de modo que eu não precise alterar ou desativar meu alerta, basta alterar esse tempo mínimo padrão:

Utilizando a inferface do SQL Server Management Studio
Para alterar esse parâmetro pelo SQL Server Management Studio, basta acessar a sessão “Management” > “Database Mail”

why-a-session-with-sp_readrequest-takes-so-long-to-execute-2

Agora, marque a opção “View or change system parameters” e clique em “Next”

why-a-session-with-sp_readrequest-takes-so-long-to-execute-3

Nesta tela é possível visualizar o valor atual e definir um novo valor do parâmetro “Database Mail Executable Minimium Lifetime (seconds)”.

why-a-session-with-sp_readrequest-takes-so-long-to-execute-4

Utilizando Transact-SQL
Para visualizar o valor padrão do parâmetro “” utilizando comandos Transact-SQL (TSQL), basta utilizar a query abaixo:

why-a-session-with-sp_readrequest-takes-so-long-to-execute-5

E se você quiser alterar o valor do parâmetro, basta realizar um UPDATE na tabela msdb.dbo.sysmail_configuration:

ou executar a stored procedure sysmail_configure_sp:

Um ponto importante que deve ser levado em consideração, é que esse parâmetro serve para limitar o tempo mínimo que o processo do DatabaseMail irá executar a cada conexão.

Com um tempo mínimo muito alto, o processo ficará ativo na instância, mesmo que não tenha nenhuma mensagem para entregar.

Se você definir um tempo mínimo muito baixo, o processo irá ficar ativo na instância por menos tempo, mas também irá gerar mais conexões e desconexões na instância para processar essa atividade, causando um pequeno overhead por conta disso. Caso sua instância tenha sempre muitas e muitas mensagens no Database Mail para entregar, considere aumentar esse tempo mínimo para diminuir esse overhead de conexões.

Espero que vocês tenham gostado do post e até a próxima!
Abraço.

SQL Server Sessão executando há muito tempo com o comando sp_readrequest (DatabaseMail) Why a Session With sp_readrequest Takes so Long to Execute Red Gate SQL Monitor alert long-running query

SQL Server Sessão executando há muito tempo com o comando sp_readrequest (DatabaseMail) Why a Session With sp_readrequest Takes so Long to Execute Red Gate SQL Monitor alert long-running query