A segunda instância do SQL Server 2008 expira durante o login - mas apenas na primeira vez?

Question

Este é um estranho que me atormentou por um tempo agora. Ao efetuar login na segunda instância do SQL Server 2008 em um dos nossos servidores de banco de dados, obtemos um erro de tempo limite:

Cannot connect to servername\mssqlserver2.

Additional information:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. (Microsoft SQL Server)")

(Esta é a mensagem de erro ao tentar se conectar ao Microsoft SQL Server Management Studio; outras ferramentas apresentam o mesmo erro, mas, é claro, dizem isso de maneiras diferentes.)

Imediatamente re-tentando logar funciona bem, então qualquer que seja a causa é efêmera! Isso acontece independentemente do usuário ou do tipo de autenticação (os métodos de autenticação do Windows e do SQL Server são suportados nessa instância). O que é ainda mais estranho é que a primeira instância deste servidor nunca demonstrou esse problema.

O servidor é um servidor virtual do Windows Server 2008 R2, hospedado no Microsoft Hyper-V (o host é do mesmo modo o Server 2008 R2). O servidor tem 2 GB de RAM e parece estar usando regularmente 90% disso - a baixa memória pode ser a causa deste problema? Eu pude ver esta segunda instância - que não é usada com muita frequência ainda - sendo trocada para o disco, e então demorando muito para carregar de volta na memória para responder a tempo ao pedido de conexão, mas eu prefiro ter mais de apenas meu próprio palpite antes de programar um tempo de inatividade para este servidor (a primeira instância é usada regularmente) e, em seguida, apenas lançar recursos extras para ele, na esperança de que o problema desapareça.

    

Answer 1

Resolvido!

Acontece que o problema era de firewall, embora o motivo de trabalhar na segunda tentativa ainda seja um mistério para mim - geralmente, se um firewall está atrapalhando, ele permanece no maneira, não permite magicamente uma segunda tentativa através de ...

De qualquer forma, a primeira instância foi configurada para escutar na porta TCP 1433, no entanto a segunda instância foi configurada para "TCP Dynamic Ports" no 59196 (ou algo parecido); o que é tão "dinâmico" sobre uma única porta está além de mim, mas seja o que for.

A adição de uma regra de firewall ao Firewall do Windows para permitir conexões com essa porta resolveu meu problema imediatamente. Eu então dei um passo adiante, no entanto: ao invés de usar essa porta "dinâmica", eu mudei para usar a porta TCP 1432 (1434 sendo usada para conexões administrativas, ou algo assim), e modifiquei a regra de firewall para permitir essa porta em vez disso.

A configuração da porta pode ser encontrada no SQL Server Configuration Manager - > Configuração de rede do SQL Server - > Propriedades de TCP / IP - > Endereços IP; Sob esta aba, eu simplesmente modifiquei as configurações na seção IPAll, ignorando a miríade de seções IPn (que foram todas desativadas de qualquer maneira): anule a entrada "TCP Dynamic Ports" e digite 1432 para "TCP Port". A alteração dessas configurações exige que você reinicie sua instância do SQL Server.