Uma consulta termina, mas a conexão com o banco externo continua aberta. Em um servidor movimentado, repetir esse comportamento pode transformar um detalhe invisível em consumo crescente de recursos e perda de desempenho. A Microsoft reconheceu um problema relacionado a atualizações do Windows lançadas desde outubro de 2026 que afeta determinadas consultas do SQL Server a servidores vinculados.
O cenário descrito envolve consultas feitas por meio de provedores OLE DB para acessar bancos externos. Oracle e PostgreSQL estão entre os destinos conhecidos. Não há indicação de que toda instalação de SQL Server, Oracle ou PostgreSQL esteja automaticamente atingida: a configuração da integração e o uso das atualizações relacionadas fazem diferença.
O que acontece com as conexões
Em uma configuração de servidor vinculado, o SQL Server pode consultar uma fonte externa sem que a aplicação tenha de tratar cada acesso como uma integração separada. A consulta é executada e, em condições normais, a infraestrutura gerencia os recursos de conexão usados nessa comunicação.
No problema reconhecido, conexões com o banco remoto podem permanecer abertas mesmo depois de a consulta associada terminar. A cada nova execução, o número de sessões acumuladas pode crescer. Dependendo da frequência das consultas e dos limites do ambiente, a consequência pode ser degradação progressiva ou instabilidade.
Isso também explica por que o sintoma pode aparecer no destino. O PostgreSQL ou o Oracle pode mostrar mais sessões abertas, embora a origem do comportamento esteja na cadeia de acesso a partir do SQL Server em um sistema afetado. Olhar só um dos lados da integração pode levar a um diagnóstico pela metade.
SQL Server executa consulta em servidor vinculado → o provedor acessa o banco externo → a consulta acaba → algumas conexões podem continuar abertas → sessões acumuladas pressionam recursos.
Quem deve prestar atenção
O aviso interessa principalmente às equipes que mantêm SQL Server em Windows e usam servidores vinculados para consultar fontes externas por OLE DB. A reportagem internacional que acompanhou o comunicado informa alcance em versões de Windows cliente e de Windows Server, incluindo sistemas a partir do Windows Server 2012.
Essa abrangência de sistemas não significa que todas as combinações de versões, provedores e bancos apresentem o defeito. Antes de tratar qualquer lentidão como esse incidente, confira o histórico de atualizações do Windows, quais integrações utilizam servidores vinculados, os provedores envolvidos e o comportamento real das sessões no destino.
É especialmente útil comparar períodos de carga e observar se o número de conexões externas aumenta sem retornar ao padrão esperado depois que as consultas terminam. Uma fotografia isolada com várias conexões não basta: aplicações podem manter sessões abertas por motivos legítimos, inclusive reutilização de conexões.
Reiniciar pode aliviar, mas não corrige a causa
Segundo o relato baseado no aviso da Microsoft, administradores podem conseguir encerrar conexões que ficaram abertas ou reiniciar o serviço SQL para aliviar temporariamente o ambiente. Nenhuma dessas medidas deve ser tratada como correção definitiva: o acúmulo pode voltar enquanto a causa permanecer.
Além disso, reiniciar um serviço de banco de dados interrompe operações em andamento e pode afetar aplicações dependentes. Encerrar sessões indiscriminadamente também pode interromper trabalho legítimo. O caminho responsável é identificar as conexões, avaliar o impacto com a equipe responsável e agir dentro dos procedimentos e da janela operacional da organização.
A Microsoft informou que trabalha em uma atualização fora do ciclo normal para corrigir o problema e orientou clientes empresariais a procurar o suporte para uma possível mitigação. Até haver disponibilização e identificação verificáveis, não faz sentido prometer uma data exata nem recomendar um pacote específico como se já estivesse resolvido.
O que vale verificar enquanto isso
Mapeie as integrações. Identifique quais servidores vinculados são utilizados, seus destinos e respectivos provedores. Isso ajuda a separar o caminho potencialmente afetado de acessos feitos por outros mecanismos.
Observe a tendência. Registre sessões no banco de destino ao longo do tempo e relacione o crescimento às consultas e tarefas executadas. Compare com o padrão anterior às atualizações, quando houver dados históricos.
Planeje a resposta. Avalie limites de conexões, alertas e impacto de possíveis intervenções. Se houver degradação, envolva os responsáveis pelo SQL Server e pelo banco externo; os dois lados precisam compartilhar o diagnóstico.
Acompanhe o comunicado oficial. Confirme qual correção se aplica ao sistema e teste-a conforme a política de mudanças da organização. Não remova atualizações de segurança automaticamente: qualquer reversão precisa considerar riscos, dependências e orientação aplicável ao ambiente.
É o tipo de falha que não precisa derrubar o servidor imediatamente para dar trabalho: basta deixar conexões acumularem até a integração começar a respirar por aparelhos. Para quem usa linked servers com Oracle ou PostgreSQL, vale monitorar agora e preparar uma resposta coordenada. Para quem não usa esse caminho, não há motivo para presumir que o ambiente inteiro esteja comprometido. E reiniciar serviço em produção continua sendo uma decisão operacional, não um botão mágico de conserto.
