Tiempo de espera de SQL Server en el primer intento

Tengo un problema extraño cuando intento conectarme a SQL Server 2008 que se ejecuta en una segunda computadora (ambas máquinas que ejecutan Win7 de 64 bits), ya sea a través de los orígenes de datos en Visual Studio o mediante la consola de administración de SQL.

En el primer intento de conexión, se agota el tiempo de espera. El segundo intento funciona bien.

Puedo acceder a los recursos compartidos en la segunda computadora sin ninguna dificultad, simplemente parece ser la primera vez que intento conectarme a SQL para cada instancia de la aplicación. Es decir, si abro dos instancias de Visual Studio, ambas fallarán en su primer intento de conexión, pero tendrán éxito en la segunda. Tengo que conectarme dos veces para cada instancia (independientemente de la secuencia de falla / éxito en cualquier otra aplicación).

Espero que tenga sentido.

¿Algún consejo?

Creo que encontré la solución, al menos en mi caso está funcionando. Estoy usando el nombre de la instancia y esto implica automáticamente un puerto dinámico para el servicio del servidor sql. Cambié la configuración de dinámico a un puerto fijo y luego abrí el firewall en ese puerto.

Administrador de configuración de SQL Server -> Configuración de red de SQL Server -> Protocolos para 'InstanceName' -> TCP / IP -> Propiedades -> Direcciones IP -> IP todo ->

Aquí ves dos opciones:

• Puertos dinámicos TCP: 51250 (generados aleatoriamente)
• Puerto TCP: vacío: puse aquí 1433 y luego abrí el firewall (en caso de que aún no estuviera abierto). Puede poner el puerto que desee (puse 1433 porque era la única instancia. En el caso de varias instancias, debe elegir un puerto diferente para cada instancia y luego abrirlas en el firewall)

El script solía facilitar su tarea de abrir los puertos que descargué de MS y lo estoy reproduciendo aquí (los comentarios están en alemán pero deberían ser obvios):

@echo =========  Ports des SQL-Servers  ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer" 
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung" 
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker  
netsh firewall set portopening TCP 4022 "SQL-Service Broker" 
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC 
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC" 
@echo =========  Ports für Analysedienste  ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste" 
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser" 
@echo =========  Verschiedene Anwendungen  ==============
@echo Aktivieren von Port 80 für HTTP 
netsh firewall set portopening TCP 80 "HTTP" 
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL" 
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser" 
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE

Mi mejor conjetura aquí es que tienes AUTO_CLOSE activado para la base de datos. Esto significa que la base de datos debe girar cuando se conecta, que es lo que está causando el tiempo de espera inicial.

La segunda suposición es que puede estar relacionado con la resolución del nombre de host. Por lo tanto, toma demasiado tiempo resolver el nombre de host la primera vez (¿tal vez por transmisión?), Pero luego se almacena en caché en los intentos de conexión posteriores. ¿Qué estás usando para resolver el host? ¿Está en DNS? Intente cambiar la cadena de conexión para que esté en un formato de puerto IP. es decir, 192.168.100.100,1433

También puede intentar ejecutar ipconfig /flushdnsdespués de un intento de conexión exitoso y ver si luego obtiene el mismo comportamiento. La solución alternativa es poner la búsqueda en su archivo HOSTS, pero debe solucionarlo correctamente.

Se siente como un tiro largo en la oscuridad con los ojos vendados, pero podría ayudar. Hay un hilo antiguo en los foros de Microsoft SQL Developer que describe lo que parece ser el mismo problema, junto con una posible solución. Su servidor ejecuta Windows Server 2008, pero también puede ser relevante para su configuración de Win7.

La amenaza:

http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/58bd9c4d-0572-4567-8e32-82a7fd600022

Del hilo:

Sí, he solucionado este problema.

Mi servidor de Windows 2008 se configuró para rechazar los enlaces SASL LDAP (consulte la advertencia 2886).

Como configuré mi servidor para que no rechace tales enlaces, las conexiones del servidor SQL 2008 funcionan correctamente.

Puede consultar Microsoft KB 935834 para obtener información sobre cómo modificar la configuración de firma de LDAP (no puedo vincularlo porque soy un usuario nuevo).

¡Espero eso ayude!

Deshabilitar el firewall. Prueba de red (ping). Oler el tráfico de red al servidor sql (use wireshark )

¿Puede intentar ejecutar SQL Profiler antes de conectarse por primera vez con VS o SSMS y ver qué está sucediendo en SQL Server?

Además, ¿ha verificado los registros de eventos para ver si se está registrando algo?