时间：2021-07-01 10:21:17 帮助过：4人阅读
步骤1：在客户端连使用SSMS工具连接到测试数据库，执行下面脚本，显性事务既不提交也不回滚。模拟事务正在执行当中。
USE AdventureWorks2012;
GO
SELECT @@SPID;
BEGIN TRAN
DELETE FROM [dbo].[Products] WHERE ProductID=1;
--ROLLBACK;
输出的会话ID为59
步骤2：在测试服务器上开启Profiler跟踪一下具体信息。具体步骤略过。
步骤3：通过VMware vSphere Client的控制台连接到测试服务器，禁用网卡，然后启用网卡，模拟网络异常。（注意：玩过Vmware的应该都知道，这里不详细介绍！）
如下截图所示，在跟踪过程中，我们可以看到当我构造网络异常时，会话ID=59的事务立即回滚了。
当然你也可以使用下面函数查看日志里面的相关记录信息。如下所示：
SELECT *
FROM fn_dblog (NULL, NULL)
WHERE Operation = ‘LOP_ABORT_XACT‘;
你可以看到 LOP_BEGIN_XACT （事务开始）-> LOP_DELETE_ROWS （删除记录） -> LOP_INSERT_ROWS （插入记录） ->LOP_ABORT_XACT （事务回滚）
通过上面实验测试，我们知道当应用程序遭遇网络异常时，数据库会回滚未提交的事务。那么接下来的问题有下面几个：
1： SQL Server需要多长时间才能检测到会话的网络异常？
如上所示，我断开的是服务器的网络，会话立即就回滚了。但是如果我断开的是客户端（执行SSMS客户端的网络），那么会话回滚的时间是30秒。如下截图所示
事务开始时间为： 2017-07-27 13:48:01:820
事务回滚时间为： 2017-07-27 13:48:32.043
这个是服务器上Keep Alive参数控制的，具体位置 “SQL Server Configuration Manager”-> “SQL Server Network Configuration” -> "Protocol for MSSQLSERVER" -> "TCP/IP " 右键单击属性，如下截图所示：
30000 的单位是毫秒， 等价于30秒， 如果你将这个设置为60000 ，那么测试结果就会是60秒或超过60秒。
当然这个时间差是你断开网络的时间和事务结束的时间差，而不是事务开始时间与结束时间差，如下测试所示，截图1，由于需找到禁用网络的位置，然后又切换窗口，导致延误了几秒，这个事务开始、结束时间差为70秒。 当然这个值不可能完全等于Keep Alive的值，因为还涉及参数Keep Alive Interval的值，所以这个值玩玩是大于等于Keep Alive的值。具体后面会讲述！
2： SQL Server通过什么机制来判断当前会话遭遇了网络异常？
在这篇“ORACLE的Dead Connection Detection浅析”文章里面， 我介绍了Linux系统下TCP KeepAlive概念，顾名思义，TCP keepalive它是用来保存TCP连接的，注意它只适用于TCP连接。系统会替你维护一个timer，时间到了，就会向remote peer发送一个probe package，当然里面是没有数据的，对方就会返回一个应答，这时你就知道这个通道保持正常。与TCP keepalive有关的三个参数tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes
/proc/sys/net/ipv4/tcp_keepalive_time 当keepalive起用的时候，TCP发送keepalive消息的频度。默认是2小时。
/proc/sys/net/ipv4/tcp_keepalive_intvl 当探测没有确认时，keepalive探测包的发送间隔。缺省是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes 如果对方不予应答，keepalive探测包的发送次数。缺省值是9。