Problemas consistentes de conectividade de rede do SQL Server

Artigo
12/14/2024

Observação

Antes de começar a solucionar problemas, recomendamos que você verifique os pré-requisitos e acesse a lista de verificação.

Este artigo ajuda a solucionar erros de conectividade de rede no SQL Server. Esses erros são consistentes e repetíveis todas as vezes. Eles apontam para alguns problemas de configuração, como o SQL Server não habilitar o TCP ou um firewall bloqueando a conexão. A solução de problemas se concentra em conexões TCP remotas porque é o tipo de conexão mais comum na maioria dos data centers, mas muitas das técnicas também podem ser aplicadas a pipes nomeados.

Mensagens de erro comuns

As mensagens de erro mais comuns são:

Falha no link de comunicação.
Erro geral de rede.
O nome de rede especificado está inacessível.
O SQL Server não existe ou o acesso é negado. (Isso também pode ser um erro de autenticação)
Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. O servidor não foi encontrado ou não estava acessível. Verifique se o nome de instância está correto e se o SQL Server está configurado para permitir conexões remotas.
Erro ao localizar servidor/instância especificado.
Não foi possível abrir uma conexão com o SQL Server Microsoft SQL Server, Erro:53. O caminho da rede não foi encontrado.
Nenhuma conexão pôde ser feita porque a máquina alvo a recusou ativamente.

Restrinja o escopo do problema a uma área focada

As etapas a seguir ajudam a restringir a solução de problemas a uma área focada:

Cliente: aplicativo, cadeia de conexão, driver (sem Transport Layer Security (TLS) 1.2), alias SQL (64/32 bits), arquivo hosts e sufixo DNS (Sistema de Nomes de Domínio) incorreto (nome completo conecta; nome curto falha).
SQL Server: mecanismo de banco de dados, protocolos habilitados e firewall.
Rede: alias DNS, gateway, roteador e firewall.

1. Você pode se conectar ao SQL Server localmente usando o SSMS (SQL Server Management Studio) e o TCP?

Por exemplo, use a cadeia de conexão neste formato: tcp:<ServerName>.<DomainName>.COM,1433, como tcp:sqlprod01.contoso.com,1433.

Observação

tcp adicionado antes que o nome do servidor seja minúsculo.

Se sim, o SQL Server funciona bem. O problema está relacionado ao seu firewall, rede ou cliente.

Caso contrário, o problema está relacionado ao Serviço do SQL Server.

2. Você pode se conectar à porta do SQL Server a partir da máquina cliente usando telnet?

Por exemplo, o comando para estabelecer uma conexão telnet com a instância do SQL Server é telnet <ServerName>.<DomainName>.COM 1433.

Em caso afirmativo, o problema está relacionado a drivers/provedores, segurança/SSL (Secure Sockets Layer), aliases SQL ou aplicativos.

Caso contrário, o problema está relacionado ao arquivo hosts, à rede ou ao firewall quando a etapa 1 funcionar.

Se telnet não estiver disponível como um comando, adicione-o como um recurso do Windows. Isso não requer uma reinicialização.
As versões mais recentes do Windows têm o comando Test-NetConnection do PowerShell.

Por exemplo, use o comando Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 para testar a conexão de rede com uma instância do SQL Server.

3. Você pode se conectar ao servidor usando um arquivo UDL se a etapa 2 funcionar?

Em caso afirmativo, o problema está relacionado a aplicativos, como uma cadeia de conexão incorreta ou o provedor usado pelo aplicativo, se diferente do provedor usado no arquivo UDL (Universal Data Link ).

Caso contrário, o problema está relacionado aos clientes.

4. Outros clientes podem se conectar ao SQL Server?

Em caso afirmativo, o problema está relacionado ao firewall, à rede , ao TLS 1.2 ou ao cliente.

Caso contrário, o problema está relacionado ao seu firewall ou servidor.

5. O cliente pode se conectar a outros servidores?

Em caso afirmativo, o problema está relacionado ao firewall, à rede , ao TLS 1.2 ou ao servidor.

Caso contrário, o problema está relacionado ao firewall, à rede ou ao TLS 1.2.

Serviço do SQL Server

Se o problema estiver relacionado ao Serviço do SQL Server, siga estas etapas:

Valide se o processo de serviço (sqlserver.exe) está em execução no Gerenciador de Tarefas. (Ou verifique por meio do SQL Server Configuration Manager ou services.msc se você tem várias instâncias instaladas.)

Se não estiver em execução, tente iniciar a instância. Se for uma configuração espelhada ou clusterizada, verifique se você está no nó primário ou ativo. Use o gerenciador de cluster para failover ou clusters sempre ativos para garantir que os recursos estejam online.
Valide se o log de eventos do aplicativo, os logs de cluster ou o arquivo ERRORLOG do SQL Server indicam um erro fatal acionável.

Valide se os protocolos esperados estão habilitados no SQL Server Configuration Manager e no arquivo ERRORLOG do SQL Server (consulte o exemplo a seguir).

Caso contrário, habilite-os e reinicie o SQL Server. O TCP deve sempre ser habilitado se conexões remotas forem permitidas.

2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433].
2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433].
2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ].
2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].

Em uma conexão de Administrador de Fonte de Dados SSMS, UDL ou ODBC, ignore o Navegador do SQL Server especificando o nome do servidor no formato: tcp:<ServerName>.<DomainName>.com,1433.

Observação

Usar o FQDN (nome de domínio totalmente qualificado) tcp:e o número da porta para criar uma conexão é o método mais confiável e resiliente. tcp: deve ser minúsculo.
- Se a conexão for bem-sucedida:
  - Valide se o Navegador do SQL Server está em execução. Se o SQL Server for uma instância padrão escutando na porta 1433, ela não precisará estar em execução. Você pode remover o número da porta e fazer com que ele ainda funcione.
  - Se a remoção do prefixo tcp: fizer com que ele falhe, você pode estar se conectando por meio de pipes nomeados por padrão. Você pode validar usando np:hostname\<ServerName> como o nome do servidor.
  - Se o uso do nome NetBIOS falhar, você pode ter um alias SQL que substitui o nome NetBIOS ou um sufixo DNS incorreto na configuração de rede. Além disso, verifique os aliases de 32 bits.
- Se o SSMS não conseguir se conectar, tente se conectar com um arquivo UDL ou por meio do Administrador de Fonte de Dados ODBC.
  - Tente usar o endereço IP do servidor em vez do nome do host. Você pode até tentar usar 127.0.0.1 se o servidor não estiver clusterizado e estiver escutando "qualquer".
  - Experimente drivers diferentes. Os drivers mais recentes dão suporte ao TLS 1.2 e fornecem mensagens de erro melhores.
  - Experimente protocolos diferentes: tcp:<ServerName>.<DomainName>.com,1433, np:<ServerName>.<DomainName>.com\<InstanceName>, ou lpc:<ServerName>.<DomainName>.com\<InstanceName>. Use o SQL Server Configuration Manager para fazer alterações. Em seguida, reinicie o SQL Server e use o arquivo ERORLOG para confirmar as alterações.
  - O SQL Server (2014 ou anterior) foi atualizado para dar suporte ao TLS 1.2? O cliente foi atualizado para oferecer suporte ao TLS 1.2? Esses protocolos estão habilitados?
  - Verifique se há um alias SQL no SQL Server Configuration Manager ou cliconfg.exe em todos os computadores Windows. Verifique os aliases de 64 bits e 32 bits.
  - Verifique se há mensagens de falha no arquivo ERRORLOG , como o banco de dados indisponível ou em recuperação.
  - Verifique a NETSTAT saída para validar se o SQL Server possui a porta esperada. Por exemplo, execute NETSTAT -abon > c:\temp\ports.txt a partir de um prompt de comando com permissões de administrador.
- Se o SQL Server estiver usando uma porta diferente da 1433:
  - Se você puder se conectar especificando o número da porta, mas não quando omitir o número da porta, esse será um problema do navegador do SQL Server. Isso significa que o serviço SQL Browser não é capaz de fornecer o número de porta correto para a instância do SQL Server à qual você deseja se conectar. Talvez você também precise reiniciar o serviço SQL Browser para atualizar suas informações.
  - Se você não conseguir se conectar mesmo quando especificar o número da porta, e isso só acontecer quando você se conectar remotamente, é um problema de firewall. Você deve verificar as configurações do firewall e certificar-se de que a porta é permitida para conexões de entrada e saída. Talvez você também precise criar uma regra de firewall para permitir que o aplicativo ou serviço do SQL Server se comunique por meio do firewall.
  - Se estiver usando Always On, conectar-se ao ouvinte não usará o SQL Server Browser, portanto, você precisará especificar o número da porta na cadeia de conexão. Se isso não funcionar, tente conectar-se diretamente ao nó primário em sua porta SQL normal. Se isso funcionar, o problema está relacionado ao ouvinte.

Se nenhum dos métodos acima funcionar, reinicie o computador do SQL Server.

O pior cenário é interromper o Serviço SQL Server, instalar uma nova instância ou potencialmente recompilar o computador e, em seguida, reanexar o banco de dados ou restaurar do backup. Se estiver usando TDE (criptografia de dados transparente), como o banco de dados SSISDB , verifique se as chaves de criptografia estão salvas antes de executar esta etapa. É oferecido como uma opção, pois a reconstrução às vezes pode ser mais rápida do que uma análise de causa raiz de problemas intratáveis. Para instalações clusterizadas, o impacto pode ser menor, pois você pode reconstruir um nó enquanto ele está em execução no nó alternativo.

Firewall

Em geral, o comportamento padrão do firewall é bloquear as portas do SQL Server e do navegador do SQL Server. Nesse caso, as conexões remotas falham, enquanto as locais são bem-sucedidas. Teste-o usando Test-NetConnection. Ele está disponível em todas as versões com suporte do Windows.

Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433

Verifique em qual porta o SQL Server está escutando no arquivo ERRORLOG . Pode ser necessário ativá-lo telnet adicionando-o como um recurso do Windows. Isso não requer uma reinicialização. O SQL Server também deve estar escutando no TCP. PortQry pode ser baixado do site de download da Microsoft. Se estiver usando o Navegador do SQL Server, verifique se a porta UDP 1434 está aberta no firewall e na porta TCP do SQL Server.

Rede

O cliente ou servidor de aplicativos pode se conectar ao SQL Server em um computador diferente. Talvez vários clientes em uma determinada rede ou sub-rede estejam tendo problemas para se conectar a um servidor fora da sub-rede ou em outra sub-rede específica. Um firewall de rede pode impedir que um cliente específico se conecte a um SQL Server específico. Por exemplo, o cliente pode se conectar a outros SQL Servers e outros clientes podem se conectar ao SQL Server com problema.

VPN

Se o problema ocorrer apenas em uma rede privada virtual (VPN) e não quando o laptop for trazido internamente, o fornecedor da VPN precisará resolver o problema. Você pode obter um rastreamento de rede de cliente e servidor, o que pode ajudar a mostrar o tipo de problemas que a VPN está causando. Por exemplo, os pacotes descartados são os mais prováveis. A VPN também pode alterar o roteamento interno entre o cliente e o servidor, expondo-o a outro dispositivo de rede que está bloqueando a conexão. A coleta de rastreamentos de rede em dispositivos intermediários ajuda a isolar o problema subdividindo a rede. O comando tracert pode revelar o roteamento.

Cliente

Se o problema estiver relacionado a clientes, você poderá ver os seguintes indicadores:

Outros clientes podem se conectar ao servidor normalmente.
Nenhum aplicativo pode se conectar a partir desta máquina.
Você não pode se conectar usando um administrador de fonte de dados UDL ou ODBC.

Isso pode ser causado por uma regra de firewall de saída ou sufixos DNS padrão incorretos. Tente testar com o nome do servidor totalmente qualificado, por exemplo:
```
Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
```
Isso pode ser um problema de TLS. Por exemplo, o servidor usa o TLS 1.2 e os drivers do cliente não foram atualizados para ele.

Pode haver uma entrada de arquivo hosts, um alias SQL ou um alias DNS que direciona a conexão para outro servidor. Use ping e telnet. Se eles funcionarem, mas o driver falhar, suspeite de um problema de alias SQL ou TLS.

Driver

Se o problema estiver relacionado a drivers, tente drivers diferentes.

Se alguns drivers funcionarem e outros falharem, suspeite de um problema de TLS. Baixe o driver mais recente, como o Microsoft OLE DB Driver for SQL Server ou o ODBC Driver 17 for SQL Server, e experimente.
Se estiver usando o .NET, verifique se você está usando a versão mais recente da estrutura. Se ainda falhar, deve fornecer uma mensagem de erro melhor. Você também pode baixar a versão mais recente do SQL Server Management Studio independente do SQL Server e instalá-la em qualquer cliente. Isso usa a SqlClient .NET classe.

Usuário

Se o problema estiver relacionado a usuários, peça a outro usuário que faça login nesta máquina.

Se a conexão for bem-sucedida, veja o que há de diferente no usuário com falha. Por exemplo, o perfil de usuário do Windows está corrompido ou talvez os usuários pertençam a uma unidade organizacional (UO) ou domínio diferente.
Se houver usuários de vários domínios, tente usar um usuário do mesmo domínio do servidor. Normalmente, os problemas do usuário resultam em erros de autenticação e têm um fluxo de trabalho de solução de problemas diferente.
Se não for um problema de autenticação, um log do Monitor de Processo pode ajudar a identificar problemas de permissão local que afetam a conectividade. Por exemplo, o usuário tem um nome de fonte de dados (DSN) ou algum tipo de redirecionamento do Registro para um driver diferente, uma restrição de permissão local ou algo que possa explicar a falha de conectividade.

Aplicativo

Se apenas um aplicativo específico falhar e um arquivo UDL for bem-sucedido, pode ser um problema de driver ou o aplicativo tem uma cadeia de conexão incorreta. Peça à equipe de desenvolvimento de aplicativos ou ao fornecedor terceirizado que verifique a cadeia de conexão. Você pode usar o Process Explorer de www.sysinternals.com para ver qual driver está sendo usado se o cliente não tiver certeza.

Ferramentas de rastreamento para capturar

Capture um rastreamento de rede de cliente e servidor. Execute o rastreamento SQL no cliente e no servidor ao mesmo tempo.

Instale o WireShark com o driver NCAP para rastrear quando o cliente e o servidor estiverem na mesma máquina.

Sua organização pode ter sua própria equipe de infraestrutura de rede com a qual você pode se envolver e pode ter uma ferramenta de rastreamento preferencial para executar a captura. Eles podem usar qualquer ferramenta, desde que seja salva em um formato compatível com Network Monitor (NetMon.exe) ou WireShark. O formato PCAP é o mais popular.

Execute o SQLNA (Analisador de Rede) e o SQLNAUI (SQL Network Analyzer) no rastreamento de rede para obter um relatório fácil de ler.

Mais informações

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.

Compartilhar via