导致此 SqlException 的原因：从服务器接收结果时发生传输级错误
这是完整的错误：
SqlException：从服务器接收结果时发生传输级错误。 （提供程序：共享内存提供程序，错误：1 - 在读/写操作中检测到 I/O 错误）
我开始在应用程序中的一些单元测试中间歇性地看到此消息（有超过 1100 个单元和系统测试） ）。 我正在使用 ReSharper 4.1 中的测试运行器。
另一件事，我的开发机器是VMWare虚拟机。
Here is the full error:
SqlException: A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 1 - I/O Error detected in read/write operation)
I've started seeing this message intermittently for a few of the unit tests in my application (there are over 1100 unit & system tests). I'm using the test runner in ReSharper 4.1.
One other thing, my development machine is a VMWare virtual machine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
请参阅 SQL Server 日志。 当表中有 BLOB 列并且正在读取数据（使用 nolock）时，可能会发生此错误。
我在 SQL Server 日志中发现以下消息：
这导致了一个错误：
See the SQL Server logs. This error may occur when you have a BLOB column in the table and are reading data (with nolock).
I found in my SQL Server log the following message:
This caused an error:
我们在我们的环境中看到了这一点，并将其部分追溯到查询中的“NOLOCK”提示。 我们删除了 NOLOCK 提示并将服务器设置为使用快照隔离模式，这些错误的频率大大降低了。
We saw this in our environment, and traced part of it down to the "NOLOCK" hint in our queries. We removed the NOLOCK hint and set our servers to use Snapshot Isolation mode, and the frequency of these errors was reduced quite a bit.
我们已经多次看到此错误，并尝试了不同的解决方案，但取得了不同的成功。 一个常见的潜在主题是发出错误的系统内存不足。 如果托管 Sql Server 的服务器正在运行任何其他非操作系统进程，则尤其如此。 默认情况下，SQL Server 将获取它可以获取的所有内存，然后为其他进程/驱动程序留下很少的内存。 这可能会导致不稳定的行为和间歇性消息。 最好将 SQL Server 配置为最大内存，以便留出一些空间，以防其他进程可能需要它。 示例：开发计算机上的 Visual Studio 正在同一计算机上运行 SQL Server 开发人员版本的副本。
We have seen this error a few times and tried different resolutions with varying success. One common underlying theme has been that the system giving the error was running low on memory. This is especially true if the server that is hosting Sql Server is running ANY other non-OS process. By default SQL Server will grab any memory that it can, then if leaving little for other processes/drivers. This can cause erratic behavior and intermittent messages. It is good practice to configure your SQL Server for a maximum memory that leaves some headroom is there are other processes that might need it. Example: Visual Studio on a dev machine that is running a copy of SQL Server developers edition on the same machine.
很多个月前我也遇到过这个问题。 然而，不要低估@Longhorn213的解释，但我们的行为完全相反。 我们在开发和测试中收到了错误，但在生产中却没有收到错误，因为显然负载要大得多。 我们最终容忍了开发中的这个问题，因为它是零星的，并且没有实质性地减慢进度。 我认为导致此错误的原因可能有多种，但我自己始终无法查明原因。
I ran into this many moons ago as well. However, not to discount @Longhorn213s explanation, but we had the exact opposite behavior. We received the error in development and testing, but not production where obviously the load was much greater. We ended up tolerating the issue in development as it was sporadic and didn't materially slow down progress. I think there could be several reasons for this error, but was never able to pin point the cause myself.
我们也遇到过这个错误，并发现我们正在终止与数据库服务器的 SQL 服务器连接。 客户端应用程序认为连接仍然处于活动状态，并尝试使用该连接，但由于连接已终止而失败。
We've also run across this error and figured out that we were killing a SQL server connection from the database server. The client application is under the impression that the connection is still active and tries make use of that connection, but fails because it was terminated.
我很多个月前就遇到过这个。 最重要的是，您的可用端口已用完。
首先确保您的调用应用程序已启用连接池。
如果确实如此，则检查 SQL Server 的可用端口数。
发生的情况是，如果池化关闭，则每个调用都会占用一个端口，并且默认情况下需要 4 分钟时间端口才会过期，并且您将耗尽端口。
如果池已打开，那么您需要分析 SQL Server 的所有端口，并确保有足够的端口，并在必要时扩展它们。
当我遇到此错误时，连接池已关闭，只要网站上有适当的负载，就会导致此问题。 我们在开发中没有看到它，因为负载最多为 2 或 3 人，但一旦人数超过 10 人，我们就会不断看到此错误。 我们打开池化，它修复了这个问题。
I ran into this many moons ago. Bottom line is you are running out of available ports.
First make sure your calling application has connection pooling on.
If that does then check the number of available ports for the SQL Server.
What is happening is that if pooling is off then every call takes a port and it takes by default 4 minutes to have the port expire, and you are running out of ports.
If pooling is on then you need to profile all the ports of SQL Server and make sure you have enough and expand them if necessary.
When I came across this error, connection pooling was off and it caused this issue whenever a decent load was put on the website. We did not see it in development because the load was 2 or 3 people at max, but once the number grew over 10 we kept seeing this error. We turned pooling on, and it fixed it.