Partilhar via

Solucionar problemas intermitentes ou periódicos com a conexão com o SQL Server

  • Artigo

Observação

Antes de começar a solucionar problemas, recomendamos que você verifique os pré-requisitos e acesse a lista de verificação. Para obter mais informações, consulte Artigos de autoajuda.

A estabilidade da rede é essencial para o bom funcionamento de vários serviços e aplicativos. No entanto, há momentos em que problemas de rede interrompem essa estabilidade. Este artigo ajuda você a entender e resolver problemas de rede intermitentes ou periódicos e suas mensagens de erro típicas. Esses problemas podem ser frustrantes, mas você pode resolvê-los de forma mais eficaz com uma melhor compreensão e técnicas adequadas de solução de problemas.

As mensagens de erro mais comuns

Problemas intermitentes ocorrem de forma irregular, enquanto problemas periódicos tendem a acontecer em intervalos previsíveis. Identificar o tipo de problema é a primeira etapa na solução de problemas. Quando ocorrem problemas de rede intermitentes ou periódicos, você pode encontrar as seguintes mensagens de erro:

  • Falha no link de comunicação: Este erro indica uma interrupção na comunicação entre os componentes da rede.
  • Tempo limite de conexão expirado: A conexão com o servidor expirou, sugerindo um atraso ou indisponibilidade do servidor.
  • Erro geral de rede: uma mensagem de erro geral de rede geralmente indica um problema não especificado com a rede.
  • Erro no nível de transporte: esse erro ocorre na camada de transporte, sugerindo problemas com a transmissão de dados.
  • O nome de rede especificado não está mais disponível: essa mensagem implica que o recurso de rede especificado não pode ser acessado.
  • Tempo limite do semáforo: esse erro aponta para uma condição de tempo limite relacionada ao uso de semáforos na rede.
  • A operação de espera atingiu o tempo limite: uma operação de espera excedeu o tempo permitido, normalmente devido a atrasos na rede.
  • Ocorreu um erro fatal ao ler o fluxo de entrada da rede: Esta mensagem sugere um erro crítico ao ler dados da rede.
  • Erro de protocolo no fluxo TDS: o TDS (Fluxo de Dados Tabulares) é um protocolo usado pelo SQL Server. Este erro indica um problema com o protocolo.
  • O servidor não foi encontrado ou não estava acessível: essa mensagem de erro sugere que o servidor que você está tentando acessar não está disponível ou não pode ser encontrado.
  • SQL Server não existe ou acesso negado: esse erro pode indicar a ausência do SQL Server ou um erro de autenticação ao tentar acessar o SQL Server.

Motivo

Os problemas mais comuns estão relacionados a quedas de pacotes devido a antivírus, otimização de rede, drivers de rede mais antigos, roteadores ou switches defeituosos e conexões não agrupadas no aplicativo.

Algumas causas, como o antivírus, podem ser difíceis de provar, mas ainda são comuns. Você pode ter que desinstalar e reiniciar o computador para provar isso, sem evidências claras. Criar uma exceção para o SQL Server também pode funcionar. Mas desativar o antivírus geralmente não funciona porque os drivers do filtro de rede ainda estão carregando, mesmo que não estejam sendo monitorados.

Processo de solução de problemas

Observação

Esse processo foi projetado para conexões de cliente e servidor do SQL Server. Outras comunicações, como o espelhamento do SQL Server, o Always-On e o tráfego de sincronização do Service Broker pela porta 5022, não são endereçadas.

Em geral, a solução de problemas deve ser orientada por dados, o que pode dar lugar a testes empíricos em um contexto mais focado. Se o problema for muito intermitente e os traços de rede forem difíceis de capturar, os métodos empíricos podem ser aplicados primeiro.

Coletar um relatório usando o SQLCHECK em cada computador

Execute SQLCHECK em cada computador para produzir um relatório. É útil determinar por que uma conexão pode estar falhando.

Coletar rastreamentos de rede no cliente e no servidor

  • Em computadores Windows, colete rastreamentos de rede usando SQLTRACE.

    Siga estas etapas para preparar e fazer o rastreamento. As etapas 2 e 3 só precisam ser feitas uma vez.

    1. Baixe a versão mais recente do SQLTRACE e descompacte-a em uma pasta, como C:\MSDATA.

    2. Abra o arquivo SQLTrace.ini e desative as seguintes configurações:

      BIDTrace=no, AuthTrace=no e EventViewer=no

    3. Salve o arquivo.

    4. Abra o PowerShell como administrador e altere o diretório para a pasta que contém SQLTrace.ps1.

      CD C:\MSDATA

    5. Inicie a coleta de rastreamento.

      .\SQLTrace.ps1 -start

    6. Reproduza o problema ou aguarde até que o erro ocorra.

    7. Pare o rastreamento.

      .\SQLTrace.ps1 -stop

    Uma pasta de saída é gerada no diretório atual e você pode usá-la para análise posterior.

  • Em computadores não Windows, use TCPDUMP ou WireShark para coletar uma captura de pacote.

Executar o Analisador de Rede do SQL Server

A interface do usuário do SQL Network Analyzer (SQLNAUI) fornece uma interface gráfica para selecionar arquivos de rastreamento para opções de análise e configuração. Baixe-o do SQL Network Analyzer (SQLNA).

Processe rastreamentos de cliente e servidor separadamente. Se você tiver rastreamentos encadeados, processe-os ao mesmo tempo. O tamanho total desses arquivos não deve exceder 80% da memória do seu computador. Verifique se você tem memória suficiente para processar todos os arquivos de rastreamento relacionados.

Essa ferramenta gerará um relatório de problemas suspeitos e um arquivo CSV que você pode explorar no Excel para pesquisa alternativa.

Tente localizar conversas correspondentes no rastreamento do cliente e no rastreamento do servidor. Geralmente, os endereços IP e os números de porta correspondem. No entanto, se as conexões passarem por qualquer tipo de conversão de endereço de rede ou mapeamento de porta, pode ser mais difícil e talvez seja necessário alinhar usando IDs de pacote IPV4 e comparar as cargas.

Padrões a serem procurados na análise de rastreamento de rede

Examine como as conversas terminam no NETMON ou no WireShark. Verifique se o cliente e o servidor concordam com a mesma coisa ou se contam uma história diferente.

Conexão fechada durante o handshake SSL

No pacote ServerHello, se o pacote de criptografia usado for um pacote Diffie-Hellman e o tráfego estiver entre Windows 2012 ou anterior e Windows 2016 ou posterior, esse algoritmo será alterado a partir dos patches de segurança do Windows 2016. Você deve desabilitar esse grupo de conjuntos de criptografia. Para obter mais informações, consulte Aplicativos com erros de conexão TLS são forçadamente fechados ao conectar Servidores SQL no Windows.

Se a conexão for fechada após o ClientHello, verifique se há uma incompatibilidade TLS 1.0 ou TLS 1.2 entre o cliente e o servidor. Se forem iguais, verifique os conjuntos de criptografia habilitados e os hashes habilitados em ambas as máquinas.

Para obter mais informações, consulte Captura de dados do Advanced Secure Sockets Layer.

Pacotes removidos

Visualize o final das conversas correspondentes. Se um tiver muitos pacotes retransmitidos (ou 10 pacotes Keep-Alive, com 1 segundo de intervalo) seguidos por um ACK+RESET e o outro não, ou um relatar uma resposta oportuna e o outro a vir atrasada e fechar ou redefinir a conversa, isso indica um problema com o dispositivo de rede e os pacotes são descartados ou atrasados.

Você também pode ver o relatório do cliente indicando que o servidor redefine a conversação e o relatório do servidor indicando que o cliente redefine a conversação. Isso ocorre devido a um switch ou roteador defeituoso fechando a conexão do meio e, às vezes, eles podem ser configurados para fazer isso se detectarem que a conexão está ociosa há algum tempo - muitas vezes ignorando os pacotes Keep-Alive.

Para obter mais informações sobre conexões descartadas, consulte:

Tanto o rastreamento do servidor quanto o rastreamento do cliente concordam que o problema está no cliente

Se ambos os rastreamentos mostrarem um atraso ou nenhuma resposta no cliente, ou se o cliente emitir um ACK+RESET depois de confirmar uma resposta do servidor ou, caso contrário, fechar a conexão antecipadamente durante a sequência de logon, você precisará fazer um rastreamento BID e um rastreamento NETSH no cliente para examinar dentro da pilha TCP/IP e o que o driver está pensando. Isso é comum se o antivírus ou outros drivers de filtro de rede atrasarem o recebimento do pacote ou o envio da resposta. Os tempos limite de conexão também podem ser devidos a uma resposta DNS lenta ou API de segurança lenta que foi chamada antes que o pacote SYN inicial fosse enviado pela rede.

Verifique o relatório de portas efêmeras do SQL Network Analyzer e verifique se o cliente não está ficando sem portas de saída.

Se o cliente tiver um longo atraso antes de enviar o pacote SYN, você poderá ver um padrão mostrando apenas o handshake de abertura de 3 vias TCP, seguido imediatamente, ou às vezes após o envio do pacote PreLogin, por um ACK+FIN originado do cliente.

Coletar um rastreamento de rede e um rastreamento BID para isolar problemas do cliente no Windows

  1. Abra o arquivo SQLTrace.ini e ative as seguintes configurações novamente:

    BIDTrace=Yes, AuthTrace=Yes e EventViewer=Yes

  2. Configure o BIDProviderList SQLTrace.ini para corresponder ao driver que seu aplicativo está usando.

    .NET System.Data.SqlClient está habilitado por padrão. Se esse não for o driver que você está usando, desabilite BIDProviderList adicionando # à frente da linha e remova-o do início da lista ODBC ou OLEDB. Isso capturará todos os drivers com suporte desse tipo. Para obter mais informações, consulte Configuração INI.

  3. Salve o arquivo.

  4. Abra o PowerShell como administrador e altere o diretório para a pasta que contém SQLTrace.ps1.

    CD C:\MSDATA

  5. Inicialize o registro de rastreamento BID, se estiver coletando rastreamentos BID.

    Observação

    O rastreamento de BID é ativado por padrão.

    .\SQLTrace.ps1 -setup

  6. Reinicie o serviço ou aplicativo que você está rastreando.

    Para alguns aplicativos, como pacotes do SQL Server Integration Services (SSIS), uma nova instância de DTEXEC ou ISServerExec é iniciada quando o pacote é executado, portanto, uma reinicialização não faz sentido.

  7. Inicie a coleta de rastreamento.

    .\SQLTrace.ps1 -start

  8. Reproduza o problema ou aguarde até que o erro ocorra.

  9. Pare o rastreamento.

    .\SQLTrace.ps1 -stop

Uma pasta de saída é gerada no diretório atual e você pode usá-la para análise posterior.

Para rastrear outros drivers do Microsoft SQL Server, consulte os artigos a seguir. Execute usando um rastreamento de rede.

Para rastrear drivers de terceiros, consulte a documentação do fornecedor.

Tanto o rastreamento do servidor quanto o rastreamento do cliente concordam que o problema está no servidor

Se ambos os rastreamentos mostrarem um atraso ou nenhuma resposta no servidor, ou se o servidor fechar a conexão em um ponto inesperado na sequência de login, ou se o servidor fechar muitas conexões ao mesmo tempo, isso indicará que há alguns problemas no servidor.

As causas mais prováveis são baixo desempenho do servidor, alto MAXDOP e grandes consultas paralelas e bloqueio. Isso pode causar privação de thread, impedindo que uma solicitação de logon seja tratada prontamente, especialmente se muitos tempos limite de conexão terminarem ao mesmo tempo e a coluna LoginAck mostrar "Atrasado". O arquivo SQL Server ERRORLOG pode mostrar operações de E/S demorando mais de 15 segundos, o que é outro indicador de problemas de desempenho. No rastreamento de rede, você também pode ver muitas conversas no relatório Redefinir com seis quadros ou menos, indicando que o handshake TCP de 3 vias pode não ter sido concluído. Para obter mais informações, consulte Coletar o buffer de anel de conectividade.

Execute a RingBufferConnectivity consulta e cole os resultados no Excel. Como essa é uma lista histórica, ela pode ser executada após a ocorrência do problema. Mas para um servidor ocupado, pode terminar rapidamente. Para um servidor lento, ele pode ter dados por alguns dias.

Se o aplicativo usar vários conjuntos de resultados ativos (MARS), ele terminará com um RESET como parte da sequência de fechamento. Isso é benigno se os pacotes SMP:FIN e ACK+FIN já tiverem sido enviados do cliente. O pacote SMP:FIN do servidor chegará após ACK+FIN do cliente, e o Windows emitirá um ACK+RESET e, em seguida, um RESET para quaisquer outras respostas do servidor como parte da sequência de fechamento da conexão.

Pool de conexões

Para obter mais informações, consulte Pool de conexões.

Se o pool de conexões for usado, as conversas no rastreamento de rede normalmente serão bastante longas. Você pode usar o arquivo CSV gerado pelo Analisador de Rede do SQL Server para classificar e filtrar por protocolos e quadros. Você provavelmente não verá os quadros inicial ou final se a captura de rede for inferior a meia hora. Se muitas conversas forem menores que 30 quadros do pacote SYN para o pacote ACK+FIN, isso indica conexões não agrupadas. Se eles forem misturados com algumas conversas mais longas, suspeite de conexões não agrupadas em segundo plano causadas pela execução de comandos em uma conexão não MARS durante a leitura de um conjunto de resultados.

O relatório de porta efêmera mostrará o número de novas conexões durante o tempo de vida do rastreamento. Você pode julgar a taxa de conexão pelo número de conexões por segundo.

RESET vs. ACK+RESET

ACK+RESET normalmente é visto quando o aplicativo ou o Windows aborta uma conexão. Isso geralmente ocorre devido a um erro de TCP de baixo nível. O pacote informa ao outro computador para parar de enviar imediatamente. No entanto, se o servidor estiver no meio da transmissão, um ou dois pacotes podem chegar ao cliente depois que o ACK+RESET for enviado. Como a porta está fechada, o sistema operacional envia um pacote RESET. Isso também acontece se os pacotes chegarem após o pacote ACK+FIN que não faz parte do handshake de fechamento normal.

Alguns drivers de terceiros também enviam um pacote ACK+RESET para fechar a conexão em vez de um ACK+FIN. Algumas conexões de sonda também podem fazer isso. Se o pacote ACK+RESET não for precedido por pacotes Keep-Alive, pacotes retransmitidos ou Zero pacotes do Windows e vier do cliente quando um fechamento normal de ACK+FIN for esperado, ele poderá ser benigno.

Use o NETSTAT para analisar problemas de rede

O NETSTAT é coletado automaticamente ao executar SQLTrace.ps1 para coleta de dados.

Ou você pode executar NETSTAT -abon > c:\ports.txt no Prompt de Comando como administrador para coletar informações relacionadas a problemas de rede.

O arquivo ports.txt conterá uma lista de todas as portas de entrada e saída, números de porta, IDs de processo e nomes de aplicativos que possuem as portas. Você pode usar isso para ver os piores infratores e se o limite de porta foi atingido. Ative a barra de status no Bloco de Notas e desative a quebra automática de linha. A barra de status fornecerá uma contagem de linhas. Você pode dividir por dois para obter um uso aproximado da porta.

Ajuste TcpTimedWaitDelay e MaxUserPort

Se um aplicativo estiver esgotando as portas de saída no computador host e você não puder fazer alterações imediatas no aplicativo, poderá diminuir TcpTimedWaitDelay de 240 para 30 segundos, permitindo que as portas de saída sejam recicladas mais rapidamente.

Para Windows 2003 e posterior, você também pode aumentar o MaxUserPort. Para Windows Vista e posterior, você define isso por meio do NETSH comando. Esse curso de ação não elimina as ineficiências de conexões não agrupadas ou conexões em segundo plano não agrupadas, e o desenvolvedor deve ser altamente encorajado a alterar seus aplicativos para usar o pool de conexões.

Para Windows 2008 e posterior, o intervalo foi aumentado de cerca de 4.000 portas efêmeras para 16.000 portas, por padrão.

Para obter mais informações, consulte Ajustar as configurações MaxUserPort e TcpTimedWaitDelay.

Quase todos os pacotes enviados do cliente para o servidor ou do servidor para o cliente são respondidos com um pacote ACK indo na direção oposta. A camada TCP.SYS gera o ACK. Se um pacote for recebido no cliente e o rastreamento do cliente mostrar que ele está chegando, mas nenhum ACK for retornado ao servidor, isso é uma boa indicação de que o antivírus ou algum outro driver de filtro de rede perdeu ou descartou o pacote ou o manteve por um longo tempo (após o final da coleta de rastreamento de rede). Da mesma forma, se o rastreamento do servidor mostrar um pacote vindo de um cliente, mas nenhum ACK for enviado de volta ao cliente, isso indica que o antivírus do servidor no servidor pode ter um problema.

No entanto, ao carregar ou baixar uma grande quantidade de dados, os pacotes ACK podem vir após uma série de pacotes de dados para ajudar no controle do fluxo.

Os drivers antivírus e de filtro são muito difíceis de provar como os culpados. Um teste empírico é quase sempre necessário. Crie uma exceção para o aplicativo ou SQL Server no antivírus e monitore-o por 48 horas para ver se o comportamento melhora. Se uma exceção não puder ser definida, desinstale o programa antivírus e reinicie. Desativá-lo normalmente não ajuda, pois o driver do filtro antivírus ainda será carregado. Faça isso apenas como último recurso se a proteção da borda estiver instalada.

Consulte seus administradores de segurança de rede. Se a situação melhorar, talvez seja necessário trabalhar com o fornecedor do antivírus para mitigar o problema. Caso contrário, outros drivers de filtro de rede podem ser os culpados.

Habilitar a auditoria do Firewall do Windows

Para determinar se o firewall descartou algum pacote, habilite a auditoria de firewall no Windows.

Para o SQL Server, esse problema pode estar relacionado ao computador cliente ou servidor. O rastreamento de rede mostrará que a máquina recebeu um pacote, mas não respondeu. O pacote pode então ser retransmitido, novamente não obter resposta e, eventualmente, a conexão é redefinida.

Ações empíricas e outras

Portas efêmeras

Ficar sem portas efêmeras é uma causa relativamente comum de tempos limite de conexão intermitente, especialmente se você não vir o pacote SYN na conexão.

Para solicitações de entrada no servidor, as portas, como 80 ou 1433, podem levar até 64.000 conexões de entrada por endereço IP do cliente e geralmente são "ilimitadas" para todos os fins práticos.

Para conexões de saída, por outro lado, o número de portas é limitado e compartilhado entre todas as conexões do servidor. Para Windows Vista, Windows 2008 e posterior, o intervalo padrão é da porta 49152 a 65535 (2^16 = 16.384 portas).

Normalmente, as portas são mantidas por quatro minutos (240 segundos) pelo sistema operacional antes de serem recicladas e reutilizadas pelos aplicativos. Isso é para evitar a falsificação de porta por software mal-intencionado ou o redirecionamento acidental de uma nova conexão para o proprietário anterior dessa porta. Devido a esse atraso, no Windows 2003, um aplicativo cliente pode fazer apenas 17 conexões por segundo com o SQL Server, e o intervalo de portas de saída é esgotado em menos de quatro minutos. Para o Windows Vista, esse número sobe para 68 conexões por segundo.

Para aplicativos como o IIS, cada cliente HTTP pode ter uma porta de saída para o SQL Server. Para um servidor web ocupado, ficar sem portas de saída é uma possibilidade real quando a carga é alta. Um web farm pode atenuar essa situação.

Ajustar a memória máxima do servidor (MB)

Para resolver problemas relacionados à pouca memória do kernel, ajuste a memória máxima do servidor (MB).

Desativar descarregamento

Para fins de teste, você pode desabilitar alguns descarregamentos por meio de um prompt de comando administrativo:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Não mantenha essas configurações desativadas por muito tempo, a menos que elas aliviem um problema. Eles devem ser habilitados por padrão no Windows 2008 e posterior.

Para outro descarregamento, você precisa acessar as propriedades do adaptador de rede para exibi-las e desabilitá-las.

Problemas de buffer de rede VMware

O host ESX que contém a máquina virtual (VM) tem um pequeno buffer de rede que pode causar problemas de confiabilidade se houver uma intermitência no tráfego. O artigo do VMware a seguir descreve como aumentar o tamanho do buffer. Nenhuma reinicialização é necessária. Essa operação deve ser feita na máquina host ESX, não na VM.

Grande perda de pacotes no sistema operacional convidado usando VMXNET3 no ESXi

Além disso, tente mover as VMs para um servidor host ESX diferente ou mover o cliente e o servidor para o mesmo servidor host ESX e veja se o problema desaparece. Se isso acontecer, é um problema de rede básica.

Instantâneos do VMware

Verifique se há instantâneos do VMware acontecendo durante o erro e desative-os.

RSS (Receive Side Scaling) desabilitado na máquina host

Quando o RSS está desabilitado, o host do SQL Server usa apenas uma única CPU para processar todas as solicitações de rede. Isso pode aumentar a CPU para 100% e causar problemas, mesmo que os níveis das outras CPUs (e da CPU geral) sejam baixos.

Para obter mais informações, consulte Introdução ao Receive Side Scaling e Receive Side Scaling Version 2 (RSSv2).

Mais informações

Problemas de autenticação intermitente ou periódica no SQL Server

Coletar um rastreamento de rede

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.