Tengo un problema extraño al intentar conectarme a SQL Server 2008 que se ejecuta en una segunda computadora (ambas máquinas ejecutan Win7 de 64 bits), ya sea a través de las fuentes de datos en Visual Studio o mediante la propia consola de administración de SQL.
En el primer intento de conectarse, se agota el tiempo de espera. El segundo intento funciona bien.
Puedo acceder a 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 el primer intento de conectarse, pero tendrán éxito en el segundo. Tengo que conectarme dos veces para cada instancia (independientemente de la secuencia de error/éxito en cualquier otra aplicación).
Espero que tenga sentido.
¿Algún consejo?
Respuesta1
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 puerto dinámico a 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 'Nombre de instancia' --> TCP/IP --> Propiedades --> Direcciones IP --> IP todas -->
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). Puedes poner el puerto que quieras (puse 1433 porque era la única instancia. En caso de varias instancias, debes elegir para cada instancia un puerto diferente y luego abrirlas en el firewall)
El script utilizado para facilitar la tarea de abrir los puertos lo descargué de MS y lo reproduzco 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
Respuesta2
Mi mejor suposición aquí es que tienesAUTO CERRADOactivado para la base de datos. Esto significa que la base de datos necesita ponerse en marcha cuando se conecta, que es lo que provoca 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, lleva demasiado tiempo resolver el nombre de host la primera vez (¿quizás mediante transmisión?), pero luego se almacena en caché en 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 formato de puerto IP. es decir, 192.168.100.100,1433
También puede intentar ejecutarlo ipconfig /flushdnsdespués de un intento de conexión exitoso y ver si obtiene el mismo comportamiento. La solución poco fiable es colocar la búsqueda en su archivo HOSTS, pero debería solucionarlo correctamente.
Respuesta3
Se siente como una posibilidad remota en la oscuridad con los ojos vendados, pero podría ayudar. Hay un hilo antiguo en los foros de desarrolladores de Microsoft SQL que describe lo que parece ser el mismo problema, junto con una posible solución. Su servidor ejecuta Windows Server 2008, pero también podría ser relevante para su configuración de Win7.
La amenaza:
Del hilo:
Sí, he solucionado este problema.
Mi servidor Windows 2008 estaba configurado para rechazar enlaces SASL LDAP (consulte la advertencia 2886).
Como configuré mi servidor para no rechazar dichos 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 LDAP (no puedo vincularlo porque soy un usuario nuevo).
¡Espero eso ayude!
Respuesta4
¿Puede intentar ejecutar SQL Profiler antes de conectarse por primera vez con VS o SSMS y ver qué sucede en SQL Server?
Además, ¿ha revisado los registros de eventos para ver si se está registrando algo?