删除语句不响应终止会话命令

Question

四天前，一个用户在一个有 400,000,000 行的表上运行了下面的命令。它仍在运行，日志文件的大小也在增加。

delete from [table-name]

该表确实有一个未启用检查的外键约束，我知道另一个表中不存在任何行。

数据库正在启用“Is Read Committed Snapshot On”并处于简单恢复模式下运行。

在这运行了几个小时之后，我发出了一个终止会话命令，因为我们的日志文件磁盘空间不足。我添加了另一个日志文件以允许系统继续运行。

日志文件继续增长，当我使用 statusonly 运行 kill session 时，它返回此消息：

SPID 123: transaction rollback in progress. Estimated rollback completion: 0%. Estimated time remaining: 0 seconds.

我不知道如何处理这个查询以使其回滚并且也只是了解正在发生的事情，任何人都可以建议我可以查看什么？

Answer 1

我不知道如何处理这个查询以使其回滚并且也只是了解正在发生的事情，任何人都可以建议我可以查看什么？

DELETE FROM [Some400MRowTable]

价格昂贵。您删除的每一行都会被记录。当你终止会话时，巨大的事务必须回滚，这更加昂贵。所以通常你只是等待，最终它会回滚。您的替代方法是从备份中恢复。

请注意，这是在 Azure SQL 数据库和 SQL Server 2019 中添加加速数据库恢复的原因之一，它提供“即时事务回滚”，其中回滚成本不是事务所做更改数量的函数。

Answer 2

回滚是单线程的，所以需要更长的时间，虽然 4 天看起来很长，但我们不知道原始删除需要多长时间。来自 Jes Schultz Borland（链接）：

如果事务必须在行或表上锁定才能执行操作，则它必须再次获得该锁定——并且其他进程现在可能正在使用该对象。另外，请考虑回滚主要是单线程的。如果事务最初使用四个内核运行，而现在回滚只使用一个内核，则需要更多时间。

想象一下：你决定爬一座有 10,000 级楼梯的塔。您爬上 9,999 级楼梯并决定不想完成攀登。你不能希望自己走到最底层——你必须回去。但是现在，您很累了– 必须单线程执行此操作。想象一下，必须用一只脚向后跳下楼梯。

根据 BradC 的回答，如果您重新启动 SQL Server，它将在读取事务日志时继续回滚。根据您的备份/恢复计划，从备份中恢复可能是您的最佳选择。