标签: blocking

运行 SQL Server 2008；Mgmt Studio 2008。我正在处理我们为 MS CRM 4.0 实施创建的 MS SQL 作业。对于熟悉 CRM 的任何人来说，这项工作每晚清除 aSyncOperationBase 表以节省数据库大小。这是工作代码：

    Begin Transaction T1

Declare @p30Days as DateTime
Declare @p3Years as DateTime

Set @p30Days = DateAdd(d, -30, GetDate())
Set @p3Years = DateAdd(d, -1095, GetDate())

update AsyncOperationBase 
set deletionstatecode=2    
where deletionstatecode = 0 and 
statecode = 3 and 
completedon is not null and 
completedon < @p30Days   
and OperationType <> 10

update AsyncOperationBase 
set deletionstatecode=2    
where deletionstatecode = 0 and 
statecode = 3 and 
completedon is …

我有一个 .NET 应用程序，它正在获取 SQL 更新超时，我相信正在发生某种阻塞/锁定，这导致了这种情况。我在数据库上运行了一个阻塞进程报告，发现了一些潜在的罪魁祸首：17 秒的阻塞。

下面是这样的日志（有很多类似的）：

<blocked-process-report>
 <blocked-process>
  <process id="process308898748" taskpriority="0" logused="0" waitresource="OBJECT: 99:774293818:0 " waittime="17146" ownerId="66317995993" transactionname="UPDATE" lasttranstarted="2015-06-15T12:59:05.817" XDES="0x3bc9cd970" lockMode="IX" schedulerid="7" kpid="11204" status="suspended" spid="161" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2015-06-15T12:59:05.817" lastbatchcompleted="2015-06-15T12:59:05.817" clientapp=".Net SqlClient Data Provider" hostname="WORKFLOWG10" hostpid="6832" loginname="WorkflowStateUpdaterSP" isolationlevel="read committed (2)" xactid="66317995993" currentdb="99" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
   <executionStack>
    <frame line="1" stmtstart="16" sqlhandle="0x02000000cb1bb914fe051a308bd33cb2b873948749c2a96d"/>
    <frame line="1" sqlhandle="0x0200000075c8f5236facd1f18bca0258f9d4babad99091d6"/>
   </executionStack>
   <inputbuf>
UPDATE [ScheduDB].[dbo].[SP_ScheduleEvent] set DateLastProcessed = GETDATE() where ScheduleEventID = 3111573   </inputbuf>
  </process>
 </blocked-process>
 <blocking-process>
  <process status="suspended" waitresource="OBJECT: 99:774293818:0 " waittime="17182" spid="278" sbid="0" ecid="0" …

在我们的应用程序中，我们偶尔会遇到由执行sp_tables语句引起的锁定问题。

我们使用 SQL Server 2012。在我们的代码和存储过程中的查询中，我们不使用sp_tables.

我如何才能追踪谁是这次通话的责任人？至少我如何在发生此调用时登录？

我读到它也被第三方调用，在这种情况下，我如何跟踪谁负责？

编辑：

在我们的应用程序中，我们使用 Hibernate 作为 ORM，使用 c3p0 作为连接池。

编辑 2： 我们没有成功理解 sp_tables 的调用时间和调用者，但今天我们成功复制了这个问题。

似乎调用 sp_tables 以响应尝试对架构进行的失败删除。

删除失败，因为还有其他行引用了我们尝试删除的行，因此我们收到异常

SQLServerException: The DELETE statement conflicted with the REFERENCE constraint..

是否有证据表明此类错误会触发数据库上的 sp_tables？

我正在处理一个查询，以判断给定会话中哪些对象具有锁定，但我遇到了一些阻塞问题。

这是我的基本查询：

SELECT request_session_id AS session_id, 
    request_owner_id AS transaction_id,
    OBJECT_SCHEMA_NAME(resource_associated_entity_id, resource_database_id),
    OBJECT_NAME(resource_associated_entity_id, resource_database_id),
    COUNT(1) AS lock_count
FROM sys.dm_tran_locks WITH (NOLOCK)
WHERE resource_type = 'OBJECT'
GROUP BY request_session_id, request_owner_id, 
    resource_database_id, resource_associated_entity_id

当我运行此查询时，我偶尔会被实际持有锁的会话之一阻止。如果我删除OBJECT_NAME和OBJECT_SCHEMA_NAME然后我没有任何问题。我试过将信息转储到一个表中，然后在有类似问题的表中使用这些值的函数。

这让我相信问题出在OBJECT_NAME和OBJECT_SCHEMA_NAME函数中，但我不确定为什么或如何解决它。我也不确定为什么我有时会被阻止有时不会。有没有人有什么建议？

我需要一个例程来有效识别哪些查询导致阻塞。这与我之前的问题如何找到仍然持有锁的查询有关？.

我知道网上有很多关于这方面的资料，但所有这些资料都是基于活动会话上的最后一条 SQL 语句很可能是获取锁的那个（因此产生了阻塞），这并不总是真的（在我的情况下，从来没有）。

我已将 设置blocking-process-threshold为 30 秒并开始分析阻塞进程报告 (BPR)。
当达到阈值时，每次发生阻塞时都会触发这些报告。
它包含有关阻塞 spid 和阻塞 spid 的信息。

通常，阻塞 spid 会在获取并持有资源（表、页或行）锁的语句之后运行几个语句：因此，不管报告内容如何，​​我仍然不知道究竟是哪个查询导致了该阻塞。

通常 SQL Server DMV 只显示每个 的最后一个 SQL 文本session_id，与活动锁（例如sys.dm_tran_locks）相关的 DMV也没有解决这个问题。

调整阻塞的查询在这里不是最好的方法：我们的应用程序全部基于嵌入在客户端代码中的动态 SQL，我们不使用存储过程，并且基于我目前看到的阻塞，所有阻塞的查询都被正确索引并写成。

我认为解决这个问题的一个选项是收集候选查询，这可能会产生阻塞，然后使用在 BPR 上收集的时间戳和 spid 查找此信息。你同意？如果是这样，您能否指出一种使用 xEvents 以尽可能少的开销来做到这一点的方法？

有没有人有一个很好的 Sql Alert 来发送电子邮件通知，当查询阻塞发生超过几分钟时？我知道如何编写自己的代码，但是在 Internet 上似乎是一个很好的代码库。如果可能，请在没有事件通知的情况下给出答案。

我喜欢下面这个： 阻止发生时的电子邮件通知

我避免使用这些，因为它们使用我听说已被弃用的 sys.processes： 自动检测阻塞

发生阻止时的电子邮件通知

这与第一个类似，但没有那么多细节： 查找长时间运行的查询

在实施之前尝试找到好的解决方案或共识。随意发送解决方案或在下面编辑一个。

谢谢，

注意：下面的一个似乎有一个不必要的临时表步骤，可能可以消除，只需一封 sql 电子邮件。

*/
 SET NOCOUNT ON

-- Checked for currently running queries by putting data in temp table
SELECT s.session_id
    ,r.STATUS
    ,r.blocking_session_id
    ,r.wait_type
    ,wait_resource
    ,r.wait_time / (1000.0) 'WaitSec'
    ,r.cpu_time
    ,r.logical_reads
    ,r.reads
    ,r.writes
    ,r.total_elapsed_time / (1000.0) 'ElapsSec'
    ,Substring(st.TEXT, (r.statement_start_offset / 2) + 1, (
            (
                CASE r.statement_end_offset
                    WHEN - 1
                        THEN Datalength(st.TEXT)
                    ELSE r.statement_end_offset
                    END - r.statement_start_offset
                ) / 2
            ) + 1) AS …

我有一个包含约 100 个数据库的环境，所有数据库都具有相同的架构。每个数据库上都有一个存储过程，它创建一个#temp 表并删除它，并且运行非常频繁（每个用户每 30 秒左右，并且有 1000 多个用户）。它的作用远不止于此：我们正在将潜在的数千行加载到这个临时表中，然后将整个内容转储出来，基本上它聚合了一堆数据。

由于所有数据库都创建相同的临时表，它们是否都相互竞争？还是每个数据库都在 tempdb 中获得了自己的临时表版本？

似乎他们有争用，因为我看到大量PAGE_LATCH等待，都在 tempdb ( 2:3:1041580)的同一页面上，这不是 GAM、SGAM 或 PFS 页面，并且 90% 的等待似乎来自同一个页面跨所有数据库的存储过程。这些等待占服务器总等待的 90%，并导致阻塞。

我做了一个DBCC PAGE，它似乎是sysobjvalues（来自标题中的 object_ID 60）。我跑了：

SELECT OBJECT_Name(object_ID), * 
FROM sys.dm_db_database_page_allocations(2,60,NULL,NULL,'DETAILED')

我得到 153 行，不确定我在这里看到的是什么。看起来像它IN_ROW_DATA和LOB_DATA在allocation_unit_type_desc。

我在与其他文件不同的卷上有 8 个 tempdb 文件。我有 16 个内核，但我的理解是，由于它不是分配页面，因此可能无助于增加文件数量。使用 SQL Server 2017 企业版。

我觉得最好的办法是告诉开发人员在这里删除临时表，但这需要重新处理逻辑并且需要一些时间。在等待开发修复时，我还能做些什么来避免这些页面闩锁？

有没有办法确定正在等待的资源的类型/名称？

我正在查看dm_exec_sessions并请求生产服务器上的 DMV。有些查询的状态为“已暂停”，持续时间为 12 分钟，等待类型为ASYNC_NETWORK_IO。

我理解这是因为客户端应用程序获取数据的速度不够快（或者结果太大以至于客户端程序需要时间来消耗它）。

这样的查询（由于正在进行的查询而暂停ASYNC_NETWORK_IO）是否会导致该表阻塞？

该查询是 a SELECT，我看不到该查询阻止任何其他查询。因此我要问的问题是它是否有可能阻止任何东西。

例如：是否ASYNC_NETWORK_IO意味着执行正在进行或执行已完成并且客户端应用程序正在提取数据？在后一种情况下，我不明白为什么这个查询可能会阻止其他查询，因为它已经产生了结果。

查询持有的锁如下：

• 页面锁定请求方式S
• 对象锁请求方式IS

假设我有一个以下形式的查询：

INSERT INTO tableA (...) select ... from tableB;

现在，这个查询在执行时是否有可能阻止普通INSERT语句tableB？附加信息：

• 所有表都是InnoDB
• 没有显式事务（自动提交已打开）
• FOR UPDATE语句中没有子句SELECT（我什至不确定是否可以在INSERT...SELECT构造中做到这一点）
• 实际的 SELECT 查询显然更复杂，涉及分组和联合，但这些不应该改变任何东西，对吧？
• 所有查询的事务隔离级别是默认的REPEATABLE READ
• 准确的数据库版本是MariaDB 10.0.12