【问题标题】:A transport-level error has occurred when receiving results from the server [closed]从服务器接收结果时发生传输级错误[关闭]
【发布时间】:2010-06-03 02:16:52
【问题描述】:

我收到一个 SQL Server 错误:

发生了传输级错误 收到结果时 服务器。 (提供者:共享内存 提供者,错误:0 - 句柄是 无效。)

我正在运行 Sql Server 2008 SP1、Windows 2008 Standard 64 位。

这是一个 .Net 4.0 网络应用程序。当向服务器发出请求时会发生这种情况。它是间歇性的。知道如何解决吗?

【问题讨论】:

  • 如果数据库是在将 AUTO_CLOSE 设置为 True 的旧版本的 SQL Express/MSDE 上创建的,则可能会发生这种情况。或者 SQL Server 服务实例已重新启动。
  • 我可能是由您的数据库上的待处理操作引起的。这会导致数据库锁定。
  • 标记的答案不是答案。下面 Michael Olivero 的答案实际上提供了内容,并且在我遇到它时解决了问题。 (手动关闭我的开发机器上的临时 Web 服务器。)我建议更改答案。
  • @Flexo 这已作为题外话关闭?我刚刚安装了全新的 VS 2017 和 MS SQL 2016 Enterprise。虽然它在 VS 2015 社区中运行良好。
  • 这不应该是题外话。该问题与使用的代码无关,因此无法为其创建 MCVE。此外,关闭原因指出:this one was resolved in a manner unlikely to help future readers - 但是有 179k 人遇到了这个问题。

标签: sql-server-2008


【解决方案1】:

数据库连接被数据库服务器关闭。该连接在您应用的连接池中仍然有效;结果,当您获取共享连接字符串并尝试执行时,它无法访问数据库。如果您正在开发 Visual Studio,只需关闭任务栏上的临时 Web 服务器即可。

如果它发生在生产中,为您的网站重置应用程序池应该会回收连接池。

【讨论】:

  • 这个才是真正的答案。
  • 在我的特殊情况下,我在连接字符串中有一个MultipleActiveResultSets=True 设置,导致了同样的错误。
  • 对我来说,从提升的命令提示符运行 iisreset 命令解决了这个问题(我是从 Visual Studio 针对 IIS 进行调试)
【解决方案2】:

在命令提示符下尝试以下命令:

netsh interface tcp set global autotuning=disabled

这会关闭网络堆栈的自动缩放功能

【讨论】:

  • 你能提供一些关于它实际作用的细节吗?是否有任何理由反对在全局范围内设置这样的值?
  • 它关闭了网络堆栈的自动扩展能力。
  • 在 Windows XP SP3 中不起作用。 Netsh 接口在 Windows XP 中没有 tcp sub 命令,但在 Windows 7 SP1 中运行良好。
  • 我知道这很旧,但这是唯一对我有用的解决方案(大多数问题/解决方案都围绕网络服务器/应用程序,我的情况是桌面应用程序和本地网络服务器,没有 IIS 或任何东西像那样)。为什么关闭自动调整/自动缩放可以解决这个问题?
  • 就我而言,SQL Server Management Studio 的 ReOpen 解决了这个问题
【解决方案3】:

我遇到了同样的问题。我重新启动了 Visual Studio 并解决了问题

【讨论】:

  • 重启电脑对我有用。
【解决方案4】:

对于那些不使用 IIS 的用户,我在使用 Visual Studio 2010 进行调试时遇到了这个问题。我结束了所有调试器进程:WebDev.WebServer40.EXE 解决了这个问题。

【讨论】:

  • 请告诉您如何结束这些过程的步骤。我是初学者,我不知道你所说的“结束所有调试器进程”是什么意思
  • @Unbreakable 我刚刚使用了任务管理器。在任务管理器中,您可以看到名称为 WebDev.WebServer40.EXE 的所有正在运行的进程。请参阅betanews.com/2015/10/08/how-to-kill-a-windows-process 了解如何杀死 Windows 进程。
【解决方案5】:

传输级别错误通常与连接到 sql server 的连接被破坏...通常是网络。

当 sql 查询运行时间过长时,通常会抛出 Timeout Expired。

可以选择的选项很少:

  1. 检查 VPN(如果使用)或任何其他工具中的连接
  2. 重启 IIS
  3. 重启机器
  4. 优化 sql 查询。

【讨论】:

  • 简单的答案,但节省了我的时间。
【解决方案6】:

您只需停止 ASP.NET 开发服务器并再次运行项目

【讨论】:

    【解决方案7】:

    如果您通过 Microsoft SQL Server Management 连接到数据库,请关闭所有连接并重试。 连接到另一个 Azure 数据库时出现此错误,并在关闭它时为我工作。 还是不知道为什么..

    【讨论】:

    • 这是一个对我有用的修复程序。我关闭了 SQL Server Management Studio,然后再也没有看到这个错误。
    • 我不敢相信,但这确实有效。我可能是服务器一开始就饱和了,谁知道呢。还是谢谢!
    【解决方案8】:

    查看MSDN blog,其中详细说明了此错误:

    删除连接

    连接池程序在连接池中删除一个连接后 闲置了很长时间,或者如果 pooler 检测到 与服务器的连接已被切断。

    请注意,只有在尝试后才能检测到断开的连接 与服务器通信。如果发现连接不存在 不再连接到服务器,它被标记为无效。

    只有在以下情况下才会从连接池中删除无效连接 它们被关闭或回收。

    如果存在与已消失的服务器的连接,则此 即使连接池程序也可以从池中提取连接 未检测到断开的连接并将其标记为无效。

    这是因为检查连接的开销 仍然有效将消除拥有池的好处 导致再次往返服务器。

    发生这种情况时,第一次尝试使用该连接将检测到 连接已被切断,并抛出异常。

    基本上你看到的是最后一句话中的那个例外。

    从连接池中获取一个连接,应用程序会这样做 不知道物理连接没有了,尝试使用它是 假设物理连接仍然存在。

    你得到你的例外。

    这有几个常见的原因。

    1. 服务器已重新启动,这将关闭现有连接。

    在这种情况下,请查看 SQL Server 日志,通常位于: C:\Program Files\Microsoft SQL Server\\MSSQL\LOG

    如果启动的时间戳是最近的,那么我们可以怀疑 这就是导致错误的原因。尝试将此时间戳与 异常的时间。

    2009-04-16 11:32:15.62 服务器在文件中记录 SQL Server 消息 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG'。

    1. 有人或某事杀死了正在使用的 SPID。

    再次查看 SQL Server 日志。如果你找到一个杀戮,尝试 将此时间戳与异常时间相关联。

    2009-04-16 11:34:09.57 spidXX 进程 ID XX 被杀死 主机名 xxxxx,主机进程 ID XXXX。

    1. 再次出现故障转移(例如在镜像设置中),请查看 SQL Server 日志。

    如果发生故障转移,请尝试将此时间戳与时间相关联 例外。

    2009-04-16 11:35:12.93 spidXX 镜像数据库“”正在将角色从“PRINCIPAL”更改为“MIRROR”,原因是 故障转移。

    【讨论】:

      【解决方案9】:

      总是在运行大约 5 分钟后得到这个。调查发现e1iexpress的警告总是发生在失败之前。这显然是与某些 TCP/IP 适配器有关的错误。但从 WiFi 更改为硬连线并没有影响它。

      于是尝试了 B 计划并重新启动了 Visual Studio。然后效果很好。

      经过仔细研究,我注意到,当正常工作时,消息 The Thread '<No Name>' has exited with code 0 几乎恰好发生在之前尝试运行崩溃的时间。一些谷歌搜索显示,当(除其他外)服务器正在修剪线程池时,该消息就会出现。

      据推测,线程池中有一个虚假线程,每次服务器尝试“修剪”它时,它都会关闭应用程序。

      【讨论】:

        【解决方案10】:

        当您的脚本使 SQL 服务因某些原因停止时,您会收到此消息。因此,如果您再次启动 SQL 服务,您的问题可能会得到解决。

        【讨论】:

        • 请提供有关如何启动 SQL 服务的步骤。我是一个初学者,我刚刚创建了一个 asp.net mvc 5 应用程序。当我运行“enable-migrations”时一切都很好然后我运行“add-migration”sdfd一切都很好,然后当我点击更新数据库时出现这个错误。请指导我
        【解决方案11】:

        我知道这可能对每个人都没有帮助(谁知道,也许是的),但我遇到了同样的问题,过了一段时间,我们意识到原因是代码本身的问题。

        试图访问服务器的计算机位于另一个网络中,连接可以建立但随后断开。

        我们过去修复它的方法是向计算机添加静态路由,允许直接访问服务器而无需通过防火墙。

        route add –p YourServerNetwork mask NetworkMask Router 
        

        示例:

        route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 
        

        我希望它对某人有所帮助,最好有这个,至少作为一个线索,所以如果你面对它,你知道如何解决它。

        【讨论】:

          【解决方案12】:

          我在 Visual Studion 2012 开发环境中遇到同样的错误,停止 IIS Express 并重新运行应用程序,它开始工作。

          【讨论】:

            【解决方案13】:

            我遇到了同样的问题。我解决了它,截断了 SQL Server LOG。 检查是否这样做,然后告诉我们此解决方案是否对您有帮助。

            【讨论】:

              【解决方案14】:

              对我来说,解决方案完全不同。

              在我的例子中,我有一个需要 datetimestamp 参数的对象源。即使 ODS 参数 ConvertEmptyStringToNull 为真 0001 年 1 月 1 日被传递给 SelectMethod。当该日期时间被传递到 sql 服务器时,这反过来又导致了一个 sql 日期时间溢出异常。

              添加了对 datetime.year != 0001 的额外检查,这为我解决了这个问题。

              奇怪的是它会引发传输级别错误,而不是日期时间溢出错误。 反正..

              【讨论】:

              • 这不可能有关系,一定是巧合
              【解决方案15】:

              在我的例子中,“SQL Server”服务器服务停止了。当我重新启动使我能够运行查询并消除错误的服务时。

              检查您的查询以找出查询导致此服务停止的原因也是一个好主意

              【讨论】:

                【解决方案16】:

                对我来说,答案是将操作系统从 2008R2 升级到 2012R2,iisreset 或重启 apppool 的解决方案对我不起作用。 我也试过关闭 TCP Chimney Offload 设置,但我没有重启服务器,因为它是生产服务器,也没有工作。

                【讨论】:

                  【解决方案17】:

                  我们最近在业务服务器和数据库服务器之间遇到了这个错误。 我们的解决方案是在网络接口上禁用“IP 卸载”。 然后错误就消失了。

                  【讨论】:

                    【解决方案18】:

                    我发现此错误的原因之一是连接字符串中的“Packet Size=xxxxx”。如果 xxxx 的值太大,我们会看到这个错误。删除此值并让 SQL Server 处理它或保持较低,具体取决于网络功能。

                    【讨论】:

                      【解决方案19】:

                      当我尝试恢复 SQL 数据库并检查Options 选项卡中的复选框时,这发生在我身上,

                      因为它是一个独立的数据库服务器,只需关闭 SSMS 并重新打开它就解决了我的问题。

                      【讨论】:

                        【解决方案20】:

                        当数据库被删除并重新创建时会发生这种情况,一些共享资源仍然认为数据库仍然存在,因此当您重新运行执行查询以在重新创建数据库后在数据库中创建表时,将不会显示错误再次显示Command(s) completed successfully. 消息而不是错误消息Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)

                        当您删除和重新创建数据库并重新执行 DDL 查询时,只需忽略此错误即可。

                        【讨论】:

                          【解决方案21】:

                          我最近遇到了同样的问题,但我无法在谷歌中得到答案。 所以想在这里分享它,以便将来对某人有所帮助。

                          错误:

                          在执行查询时,查询将提供很少的输出,然后它会抛出以下错误。

                          "接收来自的输出时发生传输级别错误 server(TCP:provider,error:0- 指定的网络名称不再是 可用”

                          解决方案:

                          1. 检查该链接服务器的提供者
                          2. 在该提供程序属性中,为该特定提供程序启用“允许进程内”选项以解决问题。

                          【讨论】:

                            猜你喜欢
                            • 2015-05-30
                            • 1970-01-01
                            • 1970-01-01
                            • 2014-08-12
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            相关资源
                            最近更新 更多