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