我们的应用程序使用 SQL Server 应用程序锁，并且在某些情况下我们需要查看给定的锁是否存在。为此，我们从 中检索和过滤信息sys.dm_tran_locks。
这是可行的，但即使是SELECT * FROM sys.dm_tran_locks我们系统中针对此 DMV 的最简单查询 ( ) 也需要超过 100 毫秒（CPU 和持续时间），有时可能会超过 500 毫秒。这是无论是否以超级管理员用户身份运行、是否从 SSMS 运行时的情况。
full 最多返回大约 10,000 行SELECT，并且我们在具有充足 CPU 和 RAM 以及快速磁盘子系统的 VM 上运行。这个查询似乎不应该花费这么长时间。
有人以前见过这个或者知道这里可能发生什么吗？如果有帮助的话，我很乐意提供更多信息。
我试图让它们超过500 GB几张桌子碎片信息中，我使用...DETAILED的选项sys.dm_db_index_physical_stats。我在我们的预生产服务器上的生产数据库的还原副本上执行此操作，因此我不关心损害服务器上的任何性能。
我运行了它，看起来它正在串行运行，并且需要永远。有没有办法dm_db_index_physical_stats()并行运行？或者是否有任何其他设置干扰它？
我想DBCC TRACEON (8649)并且OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'))在 SQL Server 2014 中不可用。
还试图DBCC SETCPUWEIGHT(1000);从保罗·怀特的博客在这里。该博客提到了并行抑制器，其中之一是系统表。被dm_db_index_physical_stats()认为是系统表吗？