客户端危险地打开了 SQL Server 2005 实例。VB.NET 1.1 可以从另一台服务器连接到此实例，没有任何问题。打开 Windows 防火墙并将端口 1433 向子网开放似乎只是一种权宜之计。
DB 似乎没问题，但一小时后速度开始变慢……好像它正在失去池中的连接。最终无法通过应用程序或其他工具进行连接。
SQL Server 是否要求打开其他端口？
这里有一位 Linux 专家正在挠头。
答案1
SQL Server 提供了一种在“SQL Server Management Studio”下监视打开连接的方法。我将检查以确保连接没有从应用程序打开并保持打开状态。因为除非应用程序明确关闭连接，否则它可能会保持打开状态，直到垃圾收集器决定最终清理对象并将连接释放回池。
检查是否发生这种情况的另一种方法是等到应用程序无法再连接。一旦处于这种状态，如果重新启动应用程序可以解决此问题，则可能是应用程序代码存在问题。
答案2
假设您正在使用默认设置运行 SQL Server，那么 1433 应该是您需要打开的唯一端口。
关于减速部分 - 使用我的Perfmon 监控教程收集有关 SQL Server 的统计信息。从那里我们可以确定服务器的哪个部分是瓶颈。如果您愿意，可以在服务器运行速度快时收集本文中显示的统计数据几分钟，然后在服务器运行速度慢时再次收集。收集这些统计数据不会对性能产生影响。然后将文件发送给我[电子邮件保护]我应该能够很快知道瓶颈在哪里。
答案3
运行 sp_who2 查看谁已连接以及他们使用什么。
JR
答案4
当无法再建立连接时，您可以在盒子上进行本地连接吗？如果可以，请尝试使用 Management Studio 再次连接，但不要使用“共享内存”，而要使用“TCP/IP”。
如果后者失败了，那么我确实会调查防火墙的情况。但是，我不会将防火墙设置与“随时间推移失去连接”联系起来。