主页 / dba / 问题 / 264416
Accepted
David Woakes
Asked: 2020-04-07 05:10:20 +0800 CST

删除语句不响应 Kill session 命令

  • 772

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

delete from [table-name]

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

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

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

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

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

我不知道如何处理这个查询以使其回滚，也只是了解发生了什么，有人能建议我看什么吗？

sql-server delete

4 个回答

  1. Best Answer

    我不知道如何处理这个查询以使其回滚，也只是了解发生了什么，有人能建议我看什么吗？

    DELETE FROM [Some400MRowTable]

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

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

    • 9

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

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

    想象一下：你决定爬一座有 10,000 级楼梯的塔。您到达 9,999 级楼梯并决定不想完成攀登。你不能希望自己走到最后一步——你必须退后一步。但是现在，你累了——不得不单线程处理。想象一下，必须一只脚向后跳下楼梯。

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

    • 7

  3. 所以删除在你杀死它之前只运行了“几个小时”，而现在“回滚”已经运行了 4 天？

    这远远超过了我通常期望的时间，所以我建议：

    1. 获得管理层批准
    2. 重新启动 SQL 实例。
    3. 交叉你的手指。
    4. 如果幸运的话，挂起的回滚会立即清除，数据库会恢复，每个人都会很高兴。
    5. 如果你不走运，那么回滚将在数据库恢复过程中继续，并且数据库永远不会重新联机。检查 SQL 错误日志的状态以查看是否发生这种情况。
    6. 在这种情况下，请再次停止 SQL 实例，然后在实例停止时从磁盘中删除数据库文件。
    7. 再次启动 SQL，实例将找不到数据库文件。
    8. 删除 (ghost) 数据库
    9. 从备份中恢复数据库。

    如果重新启动修复它，你很好。如果没有，那么您的情况不会更糟，那么只需从备份中进行恢复即可。

    祝你好运。

    • 4

  4. 您是否考虑过使用 TRUNCATE TABLE 而不是 DELETE？如果您尝试删除具有那么多行的表中的所有行，则 TRUNCATE TABLE 可能是更好的选择。它运行得比 DELETE 快。但是，我也明白，如果你使用它，如果需要，你可能无法回滚。如果我在使用 TRUNCATE TABLE 时对回滚有错误，其他比我聪明的人可以纠正我。

    • 0

相关问题