是什么原因导致“内部连接致命错误”
我有许多 ASP.Net 网站 (.Net v3.5) 在具有 SQL 2000 数据库后端的服务器上运行。 几个月来，我一直收到看似随机的 InvalidOperationExceptions 消息“内部连接致命错误”。 有时中间会间隔几天，而有时每天都会出现多个错误。
尽管它们共享业务和数据访问组件，但这一例外并不局限于特定的一个站点。 该错误似乎总是从 SqlClient.TdsParser.Run() 引发。 它有时是从老式的直接 SqlCommand.Execute() 调用中抛出的，而有时是从 Linq2Sql 代码中抛出的。
网络人员向我保证，他们的一端没有错误或数据包丢失。 还有其他人经历过吗？ 会不会是驱动的问题？ 到目前为止，我们还无法确定此异常的具体触发因素。
我们在 Windows Server 2003 上运行 II6。
I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.
The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.
I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.
We're running II6 on Windows Server 2003.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我正在创建一个新的 EF Core 项目，并尝试将数据库创建到外部 Linux 服务器而不是 Windows Server 或本地服务器。 经过几个小时的搜索，我发现我使用的是 MySQL，而不是 Microsoft SQL 服务器。
我发现很奇怪的是，每个人都使用 1433 而不是通常的 3306。因此，为了修复我的“内部连接致命错误”，我必须设置一个绑定到其默认端口 1433 的 SQL Server docker 实例。
实际上就是这么简单。 在 docker 存储库中查找“microsoft-mssql-server”并按照下面的描述运行该映像。 现在一切正常，我可以将数据库从 EF Core 项目推送到外部服务器。
I was creating a new EF Core project and was trying to create the database to an external Linux server instead of a Windows Server or local one. After hours of searching I found out that I am using MySQL instead of the Microsoft SQL server.
I found it weird that everyone was using 1433 instead of the usual 3306. So to fix my 'Internal connection fatal error' I had to set up a docker instance of SQL Server bound to its default port of 1433.
It literally was that simple. In the docker repo look for "microsoft-mssql-server" and run the image as described neatly in the description below. Everything works now and I am able to push my database from my EF Core project to an external server.
检查服务器的 LOG 文件夹（\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG 或类似文件夹）中是否有名为 SqlDump*.mdmp 和 SqlDump*.txt 的文件。 如果您确实发现任何问题，则必须将其提交给产品支持。
Check your server's LOG folder (\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG or similar) for files named SqlDump*.mdmp and SqlDump*.txt. If you do find any you'll have to take it to Product Support.
听起来数据库连接已断开或超时。
我们最近在从 IIS 5 连接到 SQL 2000 迁移到 IIS 6 时遇到了类似的问题。我们的问题通过增加可用的临时端口数量得到了解决。
查看 IIS 服务器对临时端口的使用情况。 默认最大数量 可用端口数通常为 4000。如果服务器上的站点特别繁忙或应用程序正在进行大量数据库调用，您可能需要考虑增加此端口数。
您可以先监控这些，看看是否超过最大限制。
在 Microsoft 知识库中搜索“MaxUserPort”和“TcpTimedWaitDelay”并进行必要的注册表更改。 确保在进行更改之前备份注册表或快照服务器。 需要重新启动才能使更改生效。
您应该仔细检查您的数据库和记录集连接在使用后是否已关闭。 不关闭将不必要地耗尽此端口范围。
无论如何，请检查存储过程的效率，因为它们可能花费的时间也比所需的时间长。
“如果您在四分钟内快速打开和关闭 4000 个套接字，您将达到客户端匿名端口的默认最大设置，并且新的套接字连接尝试将失败，直到现有的 TIME_WAIT 套接字集超时。” - 来自 http://support.microsoft.com/kb/328476
Sounds like the database connection is getting dropped or timing out.
We recently had similar issues moving to IIS 6 from IIS 5 connecting to SQL 2000. Our issue was solved by increasing number of ephemeral ports available.
Look at the usage of the ephemeral ports by the IIS server. The default max no. of ports available is normally 4000. You might want to consider increasing this if the sites on your server are particularly busy or your application is making a lot of database calls.
You can monitor these first to see if going over max limit.
Search Microsoft Knowledge base for "MaxUserPort" and "TcpTimedWaitDelay" and make necessary registry changes. Make sure you back up registry or snapshot server before making the changes. Will need to reboot for changes to take effect.
You should double check your database and recordset connection are being closed after use. Not closing will use up this port range unnecessarily.
Check the efficiency of your stored procedures anyway as they might be taking longer than they need too.
"If you rapidly open and close 4000 sockets in less than four minutes, you will reach the default maximum setting for client anonymous ports, and new socket connection attempts fail until the existing set of TIME_WAIT sockets times out." - from http://support.microsoft.com/kb/328476
在忽略这个问题几个月后，随着流量逐渐增加，它开始达到临界点。 在重负载下，包括一些爬虫，事情变得疯狂，这些错误不断涌现。
通过反复试验，我们最终找到了一些 SqlCommand 或 LINQ 查询，其 SqlConnection 在使用后没有立即关闭。 相反，由于对 LINQ 连接的误解而导致一些草率的编程，DataContext 对象仅在请求结束时而不是立即被释放（并关闭连接）。
一旦我们重构这些方法以立即使用 C#“using”块关闭连接（为下一个请求释放该池），我们就不再收到错误。 虽然我们仍然不知道连接池变得如此混乱的根本原因，但我们能够阻止这种类型的所有错误。 此问题与我发布的另一个类似错误一起解决，在此处找到： 为什么我的 SqlCommand 返回一个字符串，而它应该是一个 int？
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?