Conexão lenta ou tempo limite do SQL Server Management studio ao usar a Autenticação do Windows


23

Estou recebendo atrasos extremamente longos (10 a 30 segundos) no SQL Server Management Studio 2014 ao tentar conectar-me a uma instância do SQL Server 2012 por TCP usando a autenticação do Windows . Isso acontece ao conectar o Pesquisador de Objetos ou uma nova janela de consulta em branco. Uma vez conectado, a execução de consultas é rápida. O problema não ocorre quando eu me conecto usando a autenticação do SQL Server.

Meio Ambiente:

  • Windows 7, conectado como um usuário de domínio
  • Conexão TCP via endereço IP (não nome do host)
  • O servidor está em um local remoto conectado via VPN
  • Sem criptografia

Quando eu entrei no computador Windows 7 de um colega de trabalho com minha conta de domínio e me conectei ao mesmo SQL Server pela mesma VPN, não houve atraso. Quando o mesmo colega de trabalho entrou no meu PC com sua própria conta de domínio, ele sofreu o atraso. Esses testes mostram que o problema é exclusivo do meu PC. Além disso, o problema aparece apenas ao conectar-se a este SQL Server e VPN específicos; Posso conectar-me a outros servidores SQL na rede local via Autenticação do Windows sem demora.

Coisas que tentei sem sucesso:

  • Anti-vírus e firewall desativados
  • Renomeou a pasta "12.0" em "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" para "_12.0" para forçar o SSMS a recriar minhas configurações de usuário.
  • Forçar o protocolo de rede para TCP em vez de <default>. Eu também tentei pipes nomeados, mas meu servidor não está configurado para isso.
  • Instalei o SSMS 2012 e tentei isso em vez de 2014.
  • IPv6 desativado
  • Crl.microsoft.com para 127.0.0.1 no meu arquivo etc \ hosts.
  • Desativou o Programa de Aperfeiçoamento da Experiência do Usuário no SSMS, Visual Studio e Windows.
  • Desinstalou todos os aplicativos relacionados ao SQL Server do meu PC e reinstalou apenas 2012.

Dicas do TCPView:

  • Usando o TCPView, notei que, quando faço uma nova conexão, seu estado se torna ESTABELECIDO imediatamente, mas, em seguida, mais uma ou duas conexões com o SQL Server são tentadas e fechadas com TIME_WAIT . No computador do meu colega de trabalho, essas conexões são ESTABELECIDAS e sólidas. Portanto, tenho certeza de que essa é a fonte dos tempos limite, mas para que servem as conexões e por que elas falham? (Eu não tenho nenhum complemento no meu SSMS.)

Alguma ideia?

Atualização: Intellisense / Pista de preenchimento automático (?):

Percebi que, quando finalmente conecto, o Intellisense / Autocomplete não funciona. Isso exige conexões separadas do SSMS? Tentei desativá-los e não pareceu resolver o longo atraso na conexão.


Você já tentou executar o SSMS com a opção / log?
— Mister Magoo

@MisterMagoo tentando isso agora. Na verdade, ele não registra nada sobre suas tentativas de conexão (o arquivo não cresce ao fazer uma nova conexão). É principalmente sobre carregar certos pacotes na interface do usuário, por exemplo, "Conjunto de componentes carregados com êxito do cache". Não encontrei erros ou exceções.
— Jordan Rieger

Ok, eu não tinha certeza se sim, mas achei que valia a pena tentar rapidamente. Se você está realmente interessado no que está acontecendo, pode precisar interromper o Sysinternals Process Monitor e verificar se consegue identificar o que está acontecendo. technet.microsoft.com/en-us/library/bb896645.aspx
— Mister Magoo

Venho estudando os despejos do ProcMon há cerca de uma hora, mas há tantos eventos (até mesmo filtrados para o Ssms.exe) que não consigo fazer muito disso.
— Jordan Rieger

@MisterMagoo Tudo o que vejo é que as tentativas de conexão que vi com o TcpView estão demorando bastante (mais de 5 segundos cada). Estou baseando isso em ver o evento "TCP Connect" em uma porta local específica e, na próxima vez em que vejo algo enviado ou recebido nessa porta local, é sempre depois de pelo menos 5 segundos.
— Jordan Rieger

Respostas:


19

Tente executar um rastreamento com o SQL Profiler enquanto você e seu colega de trabalho se conectam ao servidor.
Selecione RPC, Instrução SQL e Pré-conexão - Iniciando / Concluído.
Selecione a opção Salvar resultados na tabela e compare as 2 tabelas para encontrar o gargalo.

Ou, como você está se conectando por IP, pode estar fazendo uma pesquisa de DNS reverso. Nesse caso, adicione uma entrada no seu arquivo hosts.


2
Adicionei uma entrada local etc / hosts para o endereço IP do meu servidor e tentei o SSMS novamente. Bingo! Super rápido. Obrigado! (Deixei o SSMS conectando via endereço IP como antes, não o nome do host.) Estou apenas me perguntando por que preciso dessa solução alternativa, mas meus colegas de trabalho não. Parece estar relacionado ao DNS. De qualquer forma, esta é uma solução muito boa para mim; portanto, concederei a você a recompensa assim que você atualizar sua resposta.
— Jordan Rieger

Eu acho que foi a pesquisa inversa porque, quando removi a entrada de hosts, o ping - um ###. ###. ###. ### estava muito lento antes do primeiro ping (pausou 5 segundos para a pesquisa inversa). Quando adicionada novamente a entrada de hosts, o ping -a era rápido. Não houve diferença no tracert ou no nslookup. Eu acho que algo deve estar diferente no meu PC, o que está fazendo com que eu faça a pesquisa inversa quando meus colegas de trabalho não são (ou é muito mais rápido deles). Aliás, meu Intellisense funciona novamente agora que a velocidade da conexão é rápida.
— Jordan Rieger

Mesmo uma entrada DNS falsa para o IP no arquivo hosts torna esse trabalho muito mais rápido! Obrigado!
— Felipez

Eu estava com tempos limite tentando conectar o SSMS através de uma VPN até ler sua resposta, sim, faz sentido porque eu estava me conectando ao servidor via IP e a resolução de nomes não estava funcionando. A adição de uma entrada no arquivo host finalmente o fez funcionar após muitas horas tentando fazê-lo funcionar. Obrigado! Como nota de rodapé, quero dizer que estou usando a autenticação do Windows de diferentes domínios com o runas / netonly e que funciona bem com esta solução.
— RobbZ

5

O que você deve verificar primeiro são as configurações de DNS do servidor ou cliente

Não é raro o seu SQL Server ter o problema de conexão com o Active Directory. Se você tentar com uma conta local do Windows, tenho certeza de que você não terá o problema. Não é incomum que o servidor esteja configurado com DNS público da Internet e, quando o SQL Server se conectar ao DC para verificar as credenciais e verificar, ele tentará entrar em contato com o DNS público em vez do servidor DNS do AD. Como essas informações não são armazenadas no DNS público, elas falharão na verificação e causarão o atraso até que ele consiga entrar em contato com o servidor DNS ou o DC adequado via NTLM

Como você não está enfrentando o problema com outros servidores SQL, quase certamente o problema não está relacionado às configurações do AD ou DC

Dispare o comando IPConfig.exe / all do cmd para verificar os servidores DNS configurados. Você deve ter apenas servidores DNS do AD configurados. Remova todos os servidores DNS públicos e deixe apenas os servidores DNS do AD.


Você está sugerindo que o SQL Server está entrando em contato com um DNS público para pesquisar o endereço IP do controlador de domínio e isso está causando o atraso quando ele tenta validar minha autenticação do Windows? Se for esse o caso, por que funcionaria bem no PC do meu colega de trabalho na mesma rede local, na mesma VPN? Verifiquei as configurações de DNS no meu computador e havia um terceiro servidor DNS extra que meu departamento de IP havia me pedido para adicionar, que não estava presente no PC do meu colega de trabalho. Mas quando removi o servidor, fiz um ipconfig / flushdns e tentei novamente, ainda estava lento.
— Jordan Rieger

Usar o endereço IP ou o FQDN do servidor (não apenas o nome do host) fez uma enorme diferença para mim. Foi definitivamente um problema de DNS lento no meu caso.
— usar o seguinte comando

0

Estendi o C:\Windows\System32\drivers\etc\hostsarquivo adicionando uma linha como esta:

201.202.203.204     mysqlserver

201.202.203.204 é o endereço IP do seu SQL Server.

mysqlserver - qualquer nome que você gosta (você não precisa usá-lo em nenhum lugar).

Isso tornou meu servidor mais rápido.

Obrigado a: d -_- b, Jordan, Rieger, felickz, RobbZ


0

Desative o Firewall do Windows no servidor SQL para o perfil de rede do Domínio.

  • Iniciar o PowerShell
  • Executar Get-NetFirewallProfile -Profile Domainpara verificar seu estado atual
  • Se estiver ativado, execute: Set-NetFirewallProfile -Profile Domain -Enabled Falsepara desativá-lo.

Se for esse o caso, você poderá ativá-lo mais tarde e ajustar suas configurações. Ou, se você estiver em um ambiente seguro, poderá deixá-lo fora.

O estranho é que, mesmo que o Firewall do Windows bloqueie a comunicação, você ainda poderá se conectar, mas o handshake inicial e as solicitações subsequentes serão incrivelmente lentas. Minha teoria (baseada em nenhuma evidência real) é que, nesses casos, a comunicação recai no Named Pipes, que é muito mais lento entre PCs remotos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.