第一次尝试时SQL Server超时

我遇到一个奇怪的问题，我尝试通过Visual Studio中的数据源或通过SQL管理控制台本身，将其连接到第二台计算机（都是运行Win7 64位的计算机）上运行的SQL Server 2008。

首次尝试连接时，它会超时。第二次尝试效果很好。

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

我希望这是有道理的。

有什么建议吗？

我想我找到了解决方案，至少在我看来，它是可行的。我正在使用实例名称，这自动暗示了sql server服务的动态端口。我已将设置从动态更改为固定端口，然后在该端口上打开了防火墙。

SQL Server配置管理器-> SQL Server网络配置->'InstanceName'的协议-> TCP / IP->属性-> IP地址-> IP全部->

在这里，您会看到两个选择：

• TCP动态端口：51250（随机生成）
• TCP端口：空-我在这里放置了1433，然后打开了防火墙（以防尚未打开）。您可以放置​​所需的任何端口（我放置了1433，因为它是唯一的实例。如果有多个实例，则应为每个实例选择不同的端口，然后在防火墙中打开它们）

该脚本用来简化打开我从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

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

第二个猜测是它可能与主机名解析有关。因此，第一次解析主机名的时间太长（也许是通过广播？），但是随后在以后的连接尝试中将其缓存。您正在使用什么来解析主机？在DNS中吗？尝试将连接字符串更改为IP端口格式。即192.168.100.100,1433

您也可以ipconfig /flushdns在成功尝试连接后尝试运行，然后查看是否出现相同的行为。躲闪的解决方法是将查找放入您的HOSTS文件中，但是您应该正确地对其进行修复。

感觉就像戴着眼罩在黑暗中远射，但这可能会有所帮助。Microsoft SQL Developer论坛上有一个古老的话题，描述了看起来相同的问题以及可能的解决方法。他的服务器正在运行Windows Server 2008，但也可能与Win7设置有关。

线程：

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

从线程：

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

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

由于我已将服务器配置为不拒绝此类绑定，因此sql server 2008连接正常工作。

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

希望能帮助到你！

禁用防火墙。测试网络（ping）。嗅探到SQL Server的网络流量（使用wirehark）

在首次连接VS或SSMS之前，您是否可以尝试运行SQL Profiler，看看SQL Server上发生了什么？

另外，您是否检查了事件日志以查看是否有日志记录？