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

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-SQT (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

SQL, sql server, sql server 2008, sql server 2008 R2, Oracle, Oracle Database, Oracle 11g, Oracle 10g, Oracle 12c, MySQL, Firebird, Consultoria, Consultor, Programador, Programação. Desenvolvedor, Analista de Sistemas, DBA, Criação de website, Criação de Sistema Web, Vitória, Vila Velha, Guarapari, Espírito Santo, ES, Consultoria SQL em VItória, Treinamento, Curso, Prestação de serviço, prestar serviço, freelancer, freela, banco de dados, consultoria em banco de dados, consultor de banco de dados

Deixe uma resposta