Microsoft SQL Server - 查询结果巨大，导致ASYNC_NETWORK_IO等待问题

Question

我有一个Java应用程序从Microsoft SQL Server（Microsoft SQL Server 2008 R2（SP3））请求大约240万条记录

应用程序在所有主机上运行正常，除了一个。在此主机上，应用程序可以在某些情况下检索数据。但在其他一些问题上，它仍然存在。

监视MS Sql服务器表示与查询关联的SPID处于ASYNC_NETWORK_IO等待状态。

网上有一些链接可以谈论它 https://blogs.msdn.microsoft.com/joesack/2009/01/08/troubleshooting-async_network_io-networkio/

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/6db233d5-8892-4f8a-88c7-b72d0fc59ca9/very-high-asyncnetworkio?forum=sqldatabaseengine

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1df2cab8-33ca-4870-9daf-ed333a64630c/network-packet-size-and-delay-by-sql-server-sending-data-to-client?forum=sqldatabaseengine

基于以上所述，ASYNC_NETWORK_IO意味着两件事： 1.应用程序处理结果的速度很慢 2.应用程序和数据库之间的网络存在一些问题。

对于上面的＃1，我们使用tcpdumps进行了分析，发现在查询进入ASYNC_NETWORK_IO状态的情况下，应用服务器的tcp连接的窗口大小介于0和小数之间，最终仍然停留在0基于更多的分析，与数据库和应用程序之间的防火墙相关的方面也被排除在外。

所以我盯着＃2，无法理解什么可能出错。更令人费解的是，因为相同的代码已经在类似的数据加载下运行了一年多。它在其他主机上运行良好。

正在使用的JDBC驱动程序是sqljdbc4-4.0.jar。 默认情况下，它具有自适应缓冲功能，可以根据需要进行操作以减少应用程序资源。 我们使用128的默认提取大小（我认为这不是一个好的）。

所以我将尝试覆盖默认的自适应缓冲行为，尽管MS文档建议对大型结果集进行自适应缓冲是很好的。

我将更改连接设置以使用selectMethod = cursor。 并且还将fetchSize更改为1024。

现在如果它不起作用：

1. 值得研究的问题有哪些方面。
2. 假设客户端仍然存在问题，应该检查/更改哪些其他连接设置，网络设置以取得进展？

如果它确实一致，那么将连接设置更改为selectMethod = cursor

会产生什么影响？
1. 在申请方面？
2. 数据库方？

更新：我测试了将selectMethod =游标添加到连接的应用程序。但是，它会产生与上述相同的问题。

基于与团队中其他管理员的讨论 - 此时问题可能出在jdbc驱动程序或OS上（当它尝试处理网络上的数据时）。

Answer 1

经过与系统管理员，网络管理员和数据库管理员的大量讨论后，人们同意在操作系统的某个地方 - ＆gt;应用程序堆栈，来自网络的数据未被处理。与此同时，我们测试了一个解决方案，我们分解了查询以返回较小的结果。因此我们将其分解为5个查询，每个查询返回约500k条记录。

现在，当我们按顺序运行这些查询时，我们仍然遇到了同样的问题。

但是，当我们并行运行查询时，它总是成功的。

鉴于该解决方案始终有效，我们不再费心去解决问题的根本原因。

另一方面，运行该应用程序的硬件和软件也已过时。它正在运行Red Hat 5.所以，它可能需要做一些事情。