☰

SQL Server 首次尝试超时

tag-icon • tag-icon sql-server-2008 networking
SQL Server 首次尝试超时

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

第一次尝试连接时超时。第二次尝试成功。

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

我希望这是有道理的。

有什么建议吗？

答案1

我想我找到了解决方案，至少在我的情况下它是有效的。我使用的是实例名称，这自动暗示了 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

答案2

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

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

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

答案3

感觉就像蒙着眼在黑暗中摸索，但也许会有帮助。Microsoft SQL Developer 论坛上有一个老帖子，描述了看似相同的问题以及可能的解决方法。他的服务器运行的是 Windows Server 2008，但可能也适用于您的 Win7 设置。

主题：

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

来自主题：

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

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

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

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

希望能帮助到你！

答案4

您可以在第一次使用 VS 或 SSMS 连接之前尝试运行 SQL Profiler，并查看 SQL Server 上发生的情况吗？

另外，您是否检查过事件日志以查看是否记录了任何内容？

相关内容