Estou recebendo atrasos extremamente longos (10 ~ 30 segundos) no SQL Server Management Studio 2014 ao tentar se conectar a uma instância do SQL Server 2012 por TCP usando Windows Authentication . 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 acontece quando eu me conecto usando a autenticação do SQL Server.
Meio Ambiente:
- Windows 7, logado como 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 entrei no computador Windows 7 de um colega de trabalho com minha conta de domínio e me conectei ao mesmo SQL Server por meio da mesma VPN, não houve atraso. Quando o mesmo colega de trabalho fez login no meu PC com sua própria conta de domínio, ele experimentou o atraso. Esses testes mostram que o problema é exclusivo do meu PC. Além disso, o problema só aparece ao se conectar a esse SQL Server e VPN específicos; Posso me conectar a outros SQL Servers na rede local via Autenticação do Windows sem demora.
Coisas que tentei sem sucesso:
- Antivírus e firewall desativados
- Renomeamos 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.
- Force 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
- Blackhole crl.microsoft.com para 127.0.0.1 no meu arquivo etc\hosts.
- Desabilitou o Programa de Aperfeiçoamento da Experiência do Cliente no SSMS, Visual Studio e Windows.
- Desinstalei todos os aplicativos relacionados ao SQL Server do meu PC e reinstalei apenas em 2012.
Dicas do TCPView:
- Usando TCPView, notei que quando faço uma nova conexão, seu estado se torna ESTABLISHED imediatamente, mas uma ou duas conexões a mais com o SQL Server são tentadas continuamente 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? (Não tenho nenhum complemento no meu SSMS.)
Alguma ideia?
Atualização: Pista Intellisense/Autocomplete (?):
Percebi que quando finalmente me conecto, o Intellisense/Autocomplete não funciona. Eles exigem conexões separadas do SSMS? Tentei desativá-los e não pareceu resolver o longo atraso de conexão.
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 PreConnect - Iniciando/Concluído.
Selecione a opção Salvar resultados na tabela e compare as 2 tabelas para encontrar o gargalo.
Ou, já que você está se conectando por IP, pode estar fazendo uma pesquisa de DNS reverso. Em caso afirmativo, adicione uma entrada em seu arquivo hosts.
O que você deve verificar primeiro são as configurações de DNS do seu servidor ou cliente
Não é raro que seu SQL Server tenha problemas para se conectar ao Active Directory. Se você tentar com uma conta local do Windows, tenho certeza de que não terá o problema. Não é incomum que o servidor esteja configurado com DNS público de internet e quando o SQL Server se conectar ao DC para verificar as credenciais e verificá-lo, 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, não serão verificadas e isso causará o atraso até que ele consiga entrar em contato com o servidor DNS ou DC adequado através do NTLM
Como você não está enfrentando o problema com outros SQL Servers, quase certamente o problema não está relacionado às configurações do AD ou DC
Acione o comando IPConfig.exe /all do cmd para verificar os servidores DNS configurados. Você deve ter apenas os servidores DNS do AD configurados. Remova todos os servidores DNS públicos e deixe apenas os servidores DNS do AD.
Eu estendi o
C:\Windows\System32\drivers\etc\hostsarquivo adicionando uma linha como esta:201.202.203.204é o endereço IP do seu SQL Server.mysqlserver- qualquer nome que você goste (você não precisa usá-lo em nenhum lugar).Isso tornou meu servidor mais rápido.
Obrigado a: d-_-b, Jordan, Rieger, felickz, RobbZ
Desative o Firewall do Windows em seu servidor SQL para o perfil de rede de domínio.
Get-NetFirewallProfile -Profile Domainpara verificar seu estado atualSet-NetFirewallProfile -Profile Domain -Enabled Falsepara desativá-lo.Se foi isso, você pode ligá-lo novamente mais tarde e ajustar suas configurações. Ou, se você estiver em um ambiente seguro, pode deixá-lo desligado.
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 lentos. Minha teoria (baseada em nenhuma evidência real) é que, nesses casos, a comunicação recai em Named Pipes, que é muito mais lento entre PCs remotos.
Eu tive esse problema quando nos mudamos para um data center. O IPS mudou e o AD também mudou os servidores.
Para resolver, adicione a entrada do servidor nos hosts da máquina local onde o Management Studio está localizado.
adicione a entrada no arquivo host no Windows:
xx.xxx.xx.xxx servername.domain
Isso fez um DNS reverso.