← Voltar para Projetos e Artigos

Caso real de produção · Diagnóstico e procedimento de contenção · Documento de referência

1. O caso em uma frase

Uma tela de calendário parou de carregar para um único cliente de um sistema multi-tenant. Todos os outros tenants, rodando o mesmo código na mesma instância de SQL Server, seguiam normais.

Os quatro fatos que orientaram o diagnóstico

A contagem de sessões abertas revelou o número que fechou o diagnóstico: 187 conexões ativas na base daquele cliente, todas ociosas (sleeping), para um sistema com 2 ou 3 usuários simultâneos.

Definição

Abrir uma conexão com um banco de dados é uma operação cara: envolve handshake de rede, autenticação e alocação de recursos no servidor. Para evitar pagar esse custo a cada requisição, o ADO.NET mantém um pool — um conjunto de conexões já abertas e prontas para reuso.

Quando a aplicação "abre" uma conexão, ela na verdade pega emprestada uma do pool. Quando "fecha", ela devolve a conexão ao pool, que a mantém viva para a próxima requisição.

Essa é exatamente a situação do caso: as salas estavam vazias (o banco respondia em 9 ms), mas não havia chave disponível (o pool estava esgotado por conexões que ninguém devolveu).

Por que só um cliente foi afetado

Este é o detalhe que torna o caso didático. O ADO.NET mantém um pool separado para cada connection string distinta. Em um sistema multi-tenant onde cada cliente tem seu próprio banco, cada cliente tem também o seu próprio pool, isolado dos demais.

Objetivo

Listar exatamente quais sessões seriam encerradas, sem encerrar nenhuma. Este passo é apenas leitura: pode ser rodado em produção, a qualquer hora, sem efeito colateral.

-- Passo 1: apenas LISTA as sessões candidatas. Não altera nada.
SELECT
    s.session_id,
    s.status,
    s.open_transaction_count,
    DATEDIFF(MINUTE, s.last_request_end_time, GETDATE()) AS min_ocioso,
    s.host_name,
    s.program_name,
    s.login_time,
    'KILL ' + CAST(s.session_id AS VARCHAR) + ';' AS comando
FROM sys.dm_exec_sessions s
WHERE DB_NAME(s.database_id) = 'NOME_DA_BASE'      -- 1. só a base afetada
  AND s.is_user_process = 1                          -- 2. ignora processos internos
  AND s.session_id <> @@SPID                          -- 3. nunca a própria sessão
  AND s.status = 'sleeping'                         -- 4. só as que não executam nada
  AND s.open_transaction_count = 0                  -- 5. só as sem transação aberta
  AND s.program_name LIKE '%SqlClient%'            -- 6. só a aplicação, não o SSMS
  AND DATEDIFF(MINUTE, s.last_request_end_time, GETDATE()) >= 5  -- 7. ociosas há 5 min+
ORDER BY min_ocioso DESC;

As sete travas de segurança

Cada filtro do WHERE existe por um motivo. Entender o porquê de cada um é o que separa "rodar um script da internet" de "saber o que se está fazendo".

Objetivo

Executar KILL em cada sessão listada no Passo 1. O KILL encerra a sessão do lado do SQL Server, liberando o slot correspondente.

-- Passo 2: encerra as sessões. Use os MESMOS filtros do Passo 1.
DECLARE @spid INT, @sql NVARCHAR(100), @mortas INT = 0;

DECLARE cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT s.session_id
    FROM sys.dm_exec_sessions s
    WHERE DB_NAME(s.database_id) = 'NOME_DA_BASE'
      AND s.is_user_process = 1
      AND s.session_id <> @@SPID
      AND s.status = 'sleeping'
      AND s.open_transaction_count = 0
      AND s.program_name LIKE '%SqlClient%'
      AND DATEDIFF(MINUTE, s.last_request_end_time, GETDATE()) >= 5;

OPEN cur;
FETCH NEXT FROM cur INTO @spid;

WHILE @@FETCH_STATUS = 0
BEGIN
    BEGIN TRY
        SET @sql = N'KILL ' + CAST(@spid AS NVARCHAR(10));
        EXEC sp_executesql @sql;
        SET @mortas = @mortas + 1;
    END TRY
    BEGIN CATCH
        PRINT 'Falhou no SPID ' + CAST(@spid AS VARCHAR) + ': ' + ERROR_MESSAGE();
    END CATCH

    FETCH NEXT FROM cur INTO @spid;
END

CLOSE cur;
DEALLOCATE cur;

PRINT 'Sessoes encerradas: ' + CAST(@mortas AS VARCHAR);

Objetivo

Confirmar numericamente que as conexões foram liberadas, e confirmar funcionalmente que a aplicação voltou ao normal.

-- Passo 3: confere quantas conexões restaram na base
SELECT COUNT(*) AS conexoes
FROM sys.dm_exec_sessions
WHERE DB_NAME(database_id) = 'NOME_DA_BASE'
  AND program_name LIKE '%SqlClient%';

Como interpretar o número

O que registrar para o histórico

• Contagem de conexões antes do procedimento
• Quantidade de sessões efetivamente encerradas (saída do PRINT)
• Contagem de conexões depois
• Data e hora da execução
• Confirmação de que a tela voltou a carregar

Esse registro serve a dois propósitos: comprovar o diagnóstico e medir o ritmo de acúmulo. Se o número voltar a 187 em três dias, você sabe que tem até três dias para corrigir o código.

Sequência de execução

Plano B — reciclar o application pool

Se após o Passo 2 a contagem caiu mas a lentidão persistiu, o pool preso está do lado do servidor de aplicação. O comando abaixo recicla o processo do IIS:

:: Executar no servidor de aplicação, com privilégio administrativo
%windir%\system32\inetsrv\appcmd recycle apppool /apppool.name:"NOME_DO_APP_POOL"

1. "Está lento" quase nunca significa "está lento"

Uma operação que leva 9 ms e estoura em 30 s não está devagar — está parada, esperando algum recurso. Lentidão gradual e travamento por espera têm causas e soluções completamente diferentes. A primeira pergunta do diagnóstico deve ser sempre: o tempo está sendo gasto ou esperado?

2. Medir antes de otimizar

A hipótese inicial natural era query lenta na base do cliente. Um SET STATISTICS IO, TIME ON derrubou essa hipótese em 30 segundos e evitou horas de trabalho em índices que não resolveriam nada.

3. O padrão do problema conta a história

4. Paliativo é legítimo, desde que seja nomeado como tal

Glossário de bolso