【问题标题】:Best way to track locks - SQL Server跟踪锁的最佳方法 - SQL Server
【发布时间】:2016-07-16 02:02:33
【问题描述】:

我们发布了一个新的 sp,在测试期间我们发现它在运行时会阻塞其他 OLTP 事务。我们发现最初是因为新的 sp 导致表上的锁升级,我们减少了批量大小的数量并且能够避免这种情况。即使在避免锁升级之后,它仍然会阻止即将到来的 oltp 事务。 我认为它锁定了 oltp 事务正在更新的同一行。

我需要找到一种方法来跟踪新 sp 持有和释放的所有锁。我尝试了 trace/xevents(锁获取/释放),它看起来不像捕获所有锁,可能是因为它发生得太快了。

为了了解获取锁的样子,我通过 select * from atable 对其进行了测试。但它给了我不同的结果。当我们选择 * 时,它不会放置一系列页面锁,所以我应该在跟踪中看到共享页面锁。但我看到的只是获取和释放 IS 锁。

跟踪给定事务的所有锁的最佳方法是什么?

【问题讨论】:

  • 扩展事件应该已经捕获了它。您可以使用会话定义更新您的帖子吗?
  • 我认为您可以尝试在 REPEATABLE READ 隔离级别运行您的事务,并在事务提交前延迟半小时。一旦事务到达延迟语句,您可以通过查询 sys.dm_tran_locks 表来分析所占用的锁。由于事务隔离级别为 REPEATABLE READ,因此在事务提交之前不会释放任何锁。因此您将有半小时的时间来捕获所有占用的锁。

标签: sql-server database sql-server-performance


【解决方案1】:

我在一个会话中运行了以下查询

begin tran
update orderstst 
set unitprice=unitprice+1
waitfor delay '00:00:20'

并在其他会话上运行查询时在 dmv 以下运行..

select resource_database_id,request_mode,request_type,request_status,txt.text
 from sys.dm_tran_locks lck
 join
 sys.dm_exec_requests ec
 on ec.session_id=lck.request_session_id
  cross apply
  sys.dm_exec_Sql_text(ec.sql_handle) txt

我得到以下数据...

当事务仍未提交但已完成时,我再次在 dmv 上方运行。但没有得到任何输出。因为当前没有执行。

但是在 dmv 下运行,仍然会给我所有持有锁的会话的锁信息..所以你将能够识别哪个会话持有更多的锁

  select resource_database_id,request_mode,request_type,request_status
 from sys.dm_tran_locks lck
 join
 sys.dm_exec_sessions ec
 on ec.session_id=lck.request_session_id

上面的查询给了我下面的信息..

总而言之,您必须通过 sql 代理作业运行 DMV1 或 DMV2 一段时间并插入到某个表中以供以后分析..

从 SQL 2012 开始,您还可以使用扩展事件..

转到管理->扩展事件,右键单击并说,启动新会话向导。

给它一个名字并在服务器启动时检查启动

下一个屏幕让您可以选择是否选择默认模板,我为锁选择默认模板,如下所示,然后单击下一步..

在下一个屏幕中,您可以在频道中选择不同的事件,选择所有频道并在类别中执行相同操作,然后选择您感兴趣的事件,我在下面选择..

在这个界面,你可以选择actions,我选择text,sessionid

在下一个屏幕中,过滤例如 .. 仅针对数据库名称(例如 'somename')或查询(例如某些文本)收集事件..

下一个屏幕是您可以将文件保存到磁盘以供以后分析的位置。

完成其余屏幕,最后选择立即启动事件会话选项..

当你收集完数据后,转到扩展事件并停止你创建的会话。右键单击并说查看目标数据..它在屏幕下方显示你

编辑:截至 2019 年 12 月 3 日,开始新会话向导现在位于此处:

【讨论】:

  • 不幸的是,OLTP 应用程序非常敏感,某些事务的响应时间必须小于 200 毫秒。所以阻塞很短,导致事务运行大约 400-800 毫秒。所以不幸的是,计划的工作可能会错过确切的时刻..这就是为什么我试图分析确切的锁并实际上是被阻塞的行。我想知道我是否可以调整 xevents 中的一些设置来捕获所有获得的锁。我正在试验 xe
  • 您使用的是 2012 吗?事务运行或完成的影响小于 800 毫秒?
  • 您好,我们使用的是 2014 年。应用程序(财务)有严格的 SLA。因此作为其中的一部分,数据库上的这些事务不应超过 200 毫秒。
  • 感谢@TheGameiswar,看起来增加最大内存大小可以解决问题。现在在花费时间并成功捕获锁之后,我才意识到这没有用(我在想什么)正如我在之前的评论中解释的那样,我的问题是不到 1 秒的阻塞。由于“阻塞进程阈值”的最小值是 1 秒,我无法使用它。我正在测试 wait_info 和 wait_completed x 事件,它们看起来很有希望,但行为很奇怪。
  • 扩展事件捕获一切
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-10-18
  • 1970-01-01
  • 2011-09-04
  • 2012-03-01
  • 1970-01-01
相关资源
最近更新 更多