SQL Server超时第一次尝试

我遇到了一个奇怪的问题，我尝试通过Visual Studio中的数据源或通过SQLpipe理控制台本身附加到在第二台计算机上运行的SQL Server 2008（两台运行Win7 64位的计算机）。

首次尝试连接时，超时。第二次尝试正常工作。

我可以毫无困难地访问第二台计算机上的共享，这似乎是我第一次尝试连接到每个应用程序实例的SQL。也就是说，如果我打开两个Visual Studio实例，两者都将在第一次尝试连接时失败，但在第二次尝试之后成功。我必须为每个实例连接两次（不pipe其他应用程序中的失败/成功顺序如何）。

我希望这是有道理的。

任何build议？

我想我find了解决scheme，至less在我的情况下，它的工作。我正在使用实例名称，这自动暗示了一个dynamic的端口为SQL服务器服务。我已经将设置从dynamic更改为修复端口，然后在该端口上打开防火墙。

SQL Serverconfigurationpipe理器 – > SQL Servernetworkingconfiguration – >“InstanceName”的协议 – > TCP / IP – >属性 – > IP地址 – > IP全部 – >

在这里你看到两个选项：

TCPdynamic端口：51250（随机生成）
TCP端口：空 – 我放在这里1433，然后我打开防火墙（如果它尚未打开）。你可以把你想要的任何端口（我把1433，因为它是唯一的实例。如果有多个实例，你应该为每个实例select一个不同的端口，然后在防火墙中打开它们）

脚本用于简化您打开我从MS下载的端口的任务，我在这里复制它（注释是德语，但它们应该是显而易见的）：

@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

感觉就像在黑暗中戴着眼罩，但它可能有帮助。在Microsoft SQL Developer论坛上有一个古老的线索，描述了看起来是相同的问题，以及可能的修复。他的服务器运行Windows Server 2008，但也可能与您的Win7设置相关。

线程：

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

从线程：

是的，我已经解决了这个问题。

我的Windows Server 2008configuration为拒绝SASL LDAP绑定（请参阅警告2886）。

由于我已经configuration我的服务器不拒绝这样的绑定，SQL Server 2008连接工作正确。

您可以查看Microsoft KB 935834以获取有关修改LDAP签名设置的信息（由于我是新用户，因此无法链接到该设置）。

希望它有帮助！

我最好的猜测是你的数据库已经打开了AUTO_CLOSE 。这意味着数据库在连接时需要旋转，这是导致初始超时的原因。

第二个猜测是它可能与主机名parsing有关。所以，第一次parsing主机名（通过广播可能？）花费的时间太长，但随后在随后的连接尝试中被caching。你用什么来解决主机？它在DNS？尝试将连接string更改为IP，端口格式。即192.168.100.100,1433

你也可以尝试在成功的连接尝试后运行ipconfig /flushdns ，看看你是否得到相同的行为。狡猾的解决方法是把你的HOSTS文件中的查找，但你应该妥善解决它。

禁用防火墙。 testingnetworking（ping）。嗅探networkingstream量到sql server（使用wireshark ）

你能在VS或SSMS第一次连接之前尝试运行SQL Profiler，看看SQL Server上发生了什么？

此外，你检查事件日志，看是否有任何logging？