一个 SELECT 如何阻塞另一个 SELECT？

发布于 2024-09-04 14:31:45 字数 320 浏览 3 评论 0原文

我正在查看 SQL Server 2005 上 SP_WhoIsActive 的输出，它告诉我一个会话正在阻止另一个会话 - 很好。然而他们都在运行 SELECT。一个 SELECT 如何阻塞另一个 SELECT？他们不应该都获取共享锁（它们彼此兼容）吗？

更多细节：两个会话都没有未完成的事务计数 - 因此它们是独立的。

查询将视图与表连接起来。

它们是复杂的查询，连接大量表并导致 10,000 次左右的读取。

任何见解都非常感激。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

淡莣 2024-09-11 14:31:45

SELECT 语句可能会阻塞另一个 SELECT 语句。您可能会想，由于两者都只获取 S 锁，因此它们永远不应该阻塞。但阻塞发生在各种类型的资源上，而不仅仅是锁。典型的例子是内存限制。我将尝试在这里挖掘一个问题的最新答案，该答案附加了一个死锁图，该图显示 SELECT 语句，一个等待另一个并行交换运算符内存资源（缓冲区）。

已更新
这是我谈到的死锁信息的链接：我有关于死锁的数据，但我不明白为什么会发生
如果您研究死锁图，您会注意到等待列表中的以下资源：

<exchangeEvent id="Pipe894b0680" WaitType="e_waitPipeGetRow" nodeId="0">
  <owner-list>
    <owner id="process824df048"/>
  </owner-list>
  <waiter-list>
    <waiter id="process86ce0988"/>
  </waiter-list>
</exchangeEvent>

这不是锁，而是“e_waitPipeGetRow”资源，由 SELECT 拥有，并且另一个 SELECT 正在等待它。有关“查询内并行资源”的一些讨论可以在这里找到：今天的令人讨厌的术语：“查询内并行线程死锁”。虽然大多数讨论将集中在死锁问题上，但这并不意味着这些资源上不会发生普通的阻塞。 sys.dm_exec_requests 将在 wait_type 和 wait_resource 中包含正确的信息。

SELECT statements may block another SELECT statement. You're probably thinking that since both acquire only S locks, they should never block. But blocking occurs on various types of resources, not only locks. Typical example is memory constraints. I'll try to digg up a recent answer to a question here that had attached a deadlock graph that showed to SELECT statements, one waiting for the other for parallel exchange operator memory resources (buffers).

Updated
Here is the link with deadlock info I talked about: I have data about deadlocks, but I can't understand why they occur
If you study the deadlock graph, you'll notice the following resource in the wait list:

<exchangeEvent id="Pipe894b0680" WaitType="e_waitPipeGetRow" nodeId="0">
  <owner-list>
    <owner id="process824df048"/>
  </owner-list>
  <waiter-list>
    <waiter id="process86ce0988"/>
  </waiter-list>
</exchangeEvent>

This is not a lock, is a 'e_waitPipeGetRow' resource, is owned by a SELECT and another SELECT is waiting for it. Some discussion about 'intra-query parallel resources' can be found here: Today's Annoyingly-Unwieldy Term: "Intra-Query Parallel Thread Deadlocks". While most discussions are going to focus on deadlock issues, that doesn't mean that ordinary blocking cannot occur on these resources. sys.dm_exec_requests will have the proper info in wait_type and wait_resource.

回复收藏 0 原文