从Linux到MS SQL Server 2008的JDBC连接在40秒后超时

问题描述

|| [查看底部的更新] 我正在使用JDBC从运行带有2.6.32-32服务器内核的Ubuntu 10.04 LTS的计算机上的Windows 2008 R2计算机上的sql Server 2008 R2运行语句。我正在使用适用于Ubuntu的当前Sun Java 6构建版本（sun-java6-jdk 6.24-1build0.10.04.1）和MS \的当前JDBC 3.0驱动程序（sqljdbc_3.0.1301.101_enu）。 当一条语句完成的时间超过40秒且不返回ResultSet时（例如\'stmt.executeUpdate（\“ SELECT * INTO BAR FROM FOO \”）\'），该程序将终止连接重置：

Exception in thread \"main\" com.microsoft.sqlserver.jdbc.sqlServerException: Connection reset
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1352)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1339)
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1654)
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5022)
    at com.microsoft.sqlserver.jdbc.sqlServerStatement.doExecuteStatement(sqlServerStatement.java:773)
    at com.microsoft.sqlserver.jdbc.sqlServerStatement$StmtExecCmd.doExecute(sqlServerStatement.java:676)
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.executeCommand(sqlServerConnection.java:1400)
    at com.microsoft.sqlserver.jdbc.sqlServerStatement.executeCommand(sqlServerStatement.java:179)
    at com.microsoft.sqlserver.jdbc.sqlServerStatement.executeStatement(sqlServerStatement.java:154)
    at com.microsoft.sqlserver.jdbc.sqlServerStatement.executeUpdate(sqlServerStatement.java:633)
    at TestTimeout.main(TestTimeout.java:42)

如果我的陈述式确实传回ResultSet（例如\'ResultSet res = stmt.executeQuery（\“ SELECT * FROM FOO \”）\'），则连线不会逾时。 当我在Win2003R2上运行相同的语句而不针对sql2005中的数据库副本返回ResultSet时，该语句完成且未在40秒时重置连接。 我启用了日志记录功能，并比较了以未完成的sql2008R2语句结尾的sql2005语句的日志，它们与2008年查询中的连接重置消息一样，都是逐行等效的。看到在12:54:47 PM的那一行：

Jun 6,2011 12:54:07 PM com.microsoft.sqlserver.jdbc.TDSCommand onRequestComplete
FInesT: TDSCommand@7ac2b2f6 (sqlServerStatement:1 executeXXX): request complete
Jun 6,2011 12:54:07 PM com.microsoft.sqlserver.jdbc.TDSCommand startResponse
FInesT: TDSCommand@7ac2b2f6 (sqlServerStatement:1 executeXXX): Reading response...
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.TDSChannel read
FINE: TDSChannel (ConnectionID:1) read Failed:Connection reset
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.sqlServerException logException
FINE: *** sqlException:ConnectionID:1 com.microsoft.sqlserver.jdbc.sqlServerException: Connection reset Connection reset
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.sqlServerException logException
FINE: com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1352)com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1339)com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1654)com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694)com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5022)com.microsoft.sqlserver.jdbc.sqlServerStatement.doExecuteStatement(sqlServerStatement.java:773)com.microsoft.sqlserver.jdbc.sqlServerStatement$StmtExecCmd.doExecute(sqlServerStatement.java:676)com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575)com.microsoft.sqlserver.jdbc.sqlServerConnection.executeCommand(sqlServerConnection.java:1400)com.microsoft.sqlserver.jdbc.sqlServerStatement.executeCommand(sqlServerStatement.java:179)com.microsoft.sqlserver.jdbc.sqlServerStatement.executeStatement(sqlServerStatement.java:154)com.microsoft.sqlserver.jdbc.sqlServerStatement.executeUpdate(sqlServerStatement.java:633)TestTimeout.main(TestTimeout.java:42)
[...]

这是针对2005数据库的语句中对应的行：

Jun 6,2011 2:02:20 PM com.microsoft.sqlserver.jdbc.TDSCommand onRequestComplete
FInesT: TDSCommand@4737371 (sqlServerStatement:1 executeXXX): request complete
Jun 6,2011 2:02:20 PM com.microsoft.sqlserver.jdbc.TDSCommand startResponse
FInesT: TDSCommand@4737371 (sqlServerStatement:1 executeXXX): Reading response...
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSChannel logPacket
FInesT: /XXX.XXX.XXX.XXX:60091 SPID:73 TDSReader@6 (ConnectionID:1) received Packet:1 (13 bytes)
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX   .....I..........
XX XX XX XX XX                                    .....
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSCommand onResponseEOM
FInesT: TDSCommand@4737371 (sqlServerStatement:1 executeXXX): disabling interrupts
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSReader nextPacket
FInesT: TDSReader@6 (ConnectionID:1) Moving to next packet -- unlinking consumed packet
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSParser parse
FInesT: TDSReader@6 (ConnectionID:1): getNextResult: Processing TDS_DONE (0xFD)
[...] 

我使用tcpdump捕获了sql Server主机和Linux主机之间的所有流量以及所有ICMP流量，并且我注意到，在语句开始执行30秒后，2008和2005服务器都向Linux发送了一个TCP保持活动数据包。 Linux主机使用ACK确认来自2005服务器的保持活动状态，但在连接到2008服务器时，Linux主机不发送ACK，并且2008服务器在重设保持活动状态之前重传9次（每秒一次）。连接（因此需要40秒的时间直到超时）。现在，我注意到Win2003 / sql2005和Win2008R2 / sql2008R2主机传输的保持活动数据包之间存在差异：较新的OS使用窗口大小为66560的TCP窗口缩放。所以现在我想知道TCP窗口大小> 65535导致Linux计算机上的iptables或tcp / ip堆栈静默忽略该数据包。但是随后连接中的其他数据包也具有缩放的窗口大小66560，并且Linux服务器会确认它们。日志文件中没有任何内容指示这些数据包被丢弃或引起任何类型的问题。 最后一点：在解决这个问题的过程中，由于更新，我们不得不重启Linux服务器几次，并且两次连接都没有超时一两天。 所以我很困惑，我希望你们中的一个可能对我有所帮助。 更新资料 我发现可以通过在Linux服务器上禁用tcp时间戳来消除连接超时。禁用窗口缩放对这个问题没有影响。追求禁用tcp时间戳的含义对于serverfault.com来说似乎是一个问题，因此我将看到有关在此迁移该问题的信息。 更新2 比较有效的连接（Win2003 / sql2003）和不可用的连接（Win2008R2 / sql2008R2）的数据包跟踪，我注意到Win2003连接的keepalive没有选项（即使它在较早的数据包中使用tcp时间戳记也是如此） ），并且断开的连接的keepalive（除非禁用了时间戳）在keepalive中确实具有tcp选项，即时间戳。因此，现在看来，Ubuntu机器对不带tcp选项的keepalive响应，而忽略了带tcp选项的keeplives。这实际上是有关两台主机上的tcp / ip问题的问题。 最终更新 我在Linux网络开发人员列表上提出了这个问题，现在我确信该问题是由于Windows错误导致具有tcp时间戳的tcp keepalive生成错误的校验和（但显然没有其他数据包） ）。请参阅netdev列表上的线程。这个问题应该结束。     

解决方法

        事实证明，Win2008发送的带有tcp时间戳记的tcp keepalive带有错误的tcp校验和，这导致Linux主机正确地忽略了它们。这个问题几乎肯定是Windows错误，而不是编程或Linux内核问题。请参阅Linux网络开发人员列表上的该线程。     ,我看到Windows Server 2003和SQL Server与具有可启用TCP / IP卸载功能的网络适配器的计算机上的可伸缩网络包（SNP）有关的类似问题。 此处的信息和解决方案： http://support.microsoft.com/kb/948496     ,        我们目前的雇主也遇到了同样的问题。我们偶然发现，如果Windows 2008 R2服务器的“ Chimney Offload State”设置为“ Enabled”，则同样的断开连接会在40秒后发生。如果该设置设置为“自动”，则可以正常工作。     ,        当发生问题时，我们确实会看到相同的问题，“烟囱卸载状态”设置为“已启用”，但应将其禁用。 我们发现的根本原因是，服务器上应用的语义补丁之一将此标志重置为Enabled。