Sql server SQL Server：过去进程阻塞的原因

我们使用的是SQL Server 2012企业版

正常情况下，我们几乎没有任何进程被阻塞，但上周末我们遇到了非常不寻常的情况。在2小时内，我们收到的“阻塞进程”警报比去年的总和还要多。在这段时间内发出了几百次警报。然后突然之间，没有任何人的干扰，一切都回到了正常状态，从此我们再也没有遇到任何进程阻塞。我想防止这种情况再次发生

我很清楚如何找到目前可能导致阻塞的原因，但我不知道如何找到过去导致阻塞的原因，目前已经解决

我在SQLServerManagementStudio中检查了错误日志，但在发生阻塞的日期下没有任何错误日志。Windows事件查看器中也没有任何异常。我还应该去哪里查

---

能否请您提供帮助？

根据您的描述，如果您没有主动设置跟踪，即设置被阻止的进程阈值并配置警报以提供所述跟踪信息，我不太确定您是否会找到以前阻止进程的原因。你描述的情况很有趣，绝对值得关注

是一篇关于SQL Server中阻止的进程阈值配置的文章，是指向警报配置的链接

---

希望这有帮助

您可以检查此时是否有人运行了异常报告或应用程序，然后再次尝试运行。听起来像是一份要求很高的报告在做这件事。另外，检查是否有任何其他非相关应用程序在同一时刻遇到问题：可能是网络问题。显然，当您重新运行您怀疑的报告或查询时，请激活活动监视器。@JoBedard谢谢您的回答。如何检查当时运行的报告？四处询问是不可能的，因为用户太多了。请在服务器上查找名为ReportServer的数据库和名为ExecutionLOG的视图，默认情况下，它会保留60天的日志。谷歌搜索术语ExecutionLOG，因为它们是根据您的服务器版本而变化的。例如@JoBedard谢谢你，Jo。这很有帮助！谢谢你的回答和链接。我们已经建立了一些非常类似的机制。通常情况下，我们根本不会遇到任何阻塞。这就是为什么这种情况让我如此惊讶的原因。@QWE:您是否能够找到DMV的问题根源，例如

sys.dm\u传输锁

，

sys.dm\u os\u等待任务

，

sys.sysprocesses

？另外，我现在只是猜测，但是如果您可能是指SSRS报告，那么在您的原始帖子的评论部分，您可能会查询ReportServer数据库中的各种ExecutionLog视图。