jrara Asked: 2011-08-20 11:06:44 +0800 CST2011-08-20 11:06:44 +0800 CST 2011-08-20 11:06:44 +0800 CST SQL Server：当一个进程阻塞另一个进程时应该怎么做？ 772 我是一名偶然的 DBA，仍在学习。 当我从 DMV:s 或 Activity Monitor 看到某个进程正在阻塞另一个进程时，应该怎么做？ 我应该简单地杀死这些进程还是有办法“释放”或者抢占这个阻塞？ sql-server locking 4 个回答 Voted Mark Storey-Smith 2011-08-20T15:20:13+08:002011-08-20T15:20:13+08:00 尽管已经回答了这个问题并且已经接受了答案，但我将尝试为相反的方法提出理由...... 永远不要盲目地杀死蜘蛛 除非您知道 SPID 所做的工作，否则您将无法了解您将要启动的回滚的规模。 最糟糕的阻塞链是那些意外地让你的 24/7 系统崩溃的阻塞链。在 99% 的情况下，阻塞链头部的查询将是一个普通的旧选择查询出错，将其后面的所有写入活动排队。在这些情况下，一个 KILL 将拯救这一天。 另外 1% 的时间，恶意查询将是长时间运行事务的最后一步，该事务的回滚时间与进入当前阶段所需的时间一样长。花点时间了解你是如何到达这里的，99% 的时间都是不必要的。1% 的时间，您可以节省几分钟/几小时/几天的停机时间。 Best Answer gbn 2011-08-20T11:16:26+08:002011-08-20T11:16:26+08:00 杀 有时，极端暴力是答案 无论如何，一个块只是一个持续时间过长的锁。“太长”当然是可变的。如果您通过 sysprocesses 或 DMV 看到阻塞，那么它几乎总是“太长”，因为阻塞应该是瞬态的并且非常短 如果您确实有可衡量的阻塞，那么您需要调查原因，例如长时间运行的事务 Richard 2011-08-20T11:09:48+08:002011-08-20T11:09:48+08:00 阻塞本身并不坏。 当您因阻塞其他事务的长时间运行的事务而遇到性能问题时，就会出现问题。 在这种情况下，我要做的是尝试识别任何长时间运行的查询/事务并尝试解决这些问题。 如果您遇到性能问题，请尝试解决根本原因，而不是症状。 话虽如此，如果您在生产中遇到问题并且绝对需要停止它，请使用 KILL 例程。（如 gbn 所述）。 Thomas Stringer 2011-08-20T18:54:09+08:002011-08-20T18:54:09+08:00 锁定是正常的。它总是伴随着冲突发生。持续的死锁是一个问题，因为数据库引擎会选择一个受害者进程来终止和回滚事务。统计数据证明这一定会发生，但如果它不断发生，那么您需要深入了解原因并重写查询和代码逻辑。
尽管已经回答了这个问题并且已经接受了答案，但我将尝试为相反的方法提出理由......
永远不要盲目地杀死蜘蛛
除非您知道 SPID 所做的工作，否则您将无法了解您将要启动的回滚的规模。
最糟糕的阻塞链是那些意外地让你的 24/7 系统崩溃的阻塞链。在 99% 的情况下，阻塞链头部的查询将是一个普通的旧选择查询出错，将其后面的所有写入活动排队。在这些情况下，一个 KILL 将拯救这一天。
另外 1% 的时间，恶意查询将是长时间运行事务的最后一步，该事务的回滚时间与进入当前阶段所需的时间一样长。花点时间了解你是如何到达这里的，99% 的时间都是不必要的。1% 的时间，您可以节省几分钟/几小时/几天的停机时间。
杀
有时，极端暴力是答案
无论如何，一个块只是一个持续时间过长的锁。“太长”当然是可变的。如果您通过 sysprocesses 或 DMV 看到阻塞，那么它几乎总是“太长”，因为阻塞应该是瞬态的并且非常短
如果您确实有可衡量的阻塞，那么您需要调查原因，例如长时间运行的事务
阻塞本身并不坏。
当您因阻塞其他事务的长时间运行的事务而遇到性能问题时，就会出现问题。
在这种情况下，我要做的是尝试识别任何长时间运行的查询/事务并尝试解决这些问题。
如果您遇到性能问题，请尝试解决根本原因，而不是症状。
话虽如此，如果您在生产中遇到问题并且绝对需要停止它，请使用 KILL 例程。（如 gbn 所述）。
锁定是正常的。它总是伴随着冲突发生。持续的死锁是一个问题，因为数据库引擎会选择一个受害者进程来终止和回滚事务。统计数据证明这一定会发生，但如果它不断发生，那么您需要深入了解原因并重写查询和代码逻辑。