尝试更新时，SSMS中的发布属性窗口挂起

Question

我们有一个被镜像的SQL 2012数据库。它还有一个出版物，有3个订阅者。在向某个订阅服务器推送快照时出现问题(无法复制的视图)后，我试图更改属性，以便该视图不在要推送的项目列表中。我点击OK，窗户挂了起来。在活动监视器检查时，我有9个不同的小岛屿发展中国家，等待时间超过一个小时。其中大多数是SSMS应用程序中的"SELECTS“。我想我没问题就能杀了这些人。2在SSMS中，但是是“更新”命令。我还有3个挂起的SQLAgent小岛屿发展中国家:一个是“打开的光标”，一个是“删除”，一个是“选择”。还有一个“分发历史记录”应用程序SID选择是挂起的。这些小岛屿发展中国家都处于“暂停”状态。他们都在等待一个资源锁(大部分是共享的)

这是一个关键的生产数据库，当它试图做一些事情的时候，我对仅仅杀死SSMS感到紧张。有人能推荐其中之一:a-杀死SSMS接口B-杀死各种小岛屿发展中国家。如果是的话，我应该只杀某些类型的人吗？哪几个？其他的东西。

Answer 1

除了您自己之外，没有人能够为您决定哪些查询应该是KILL，因为这将具体取决于这些查询正在做什么，以及它们对您公司的业务有多重要。这与正在发生的操作类型无关(有些人的SELECT查询可能比他们的任何UPDATE和DELETE查询都重要得多)。

另外，请记住，如果您在一个大型事务中删除了一个查询，您可能也会等待一段时间，等待该事务可能回滚。

最好的操作方法是下载sp_WhoIsActive并运行它来查看所有的活动查询进程。它还将告诉您哪些进程被阻塞，以及阻止它们的进程的ID。您可以通过这种方式找到铅阻塞查询，然后确定是否应该只杀死导致所有阻塞的一个查询。sp_WhoIsActive还告诉您运行每个查询的用户(如果适用的话)，因此您还可以潜在地看到是谁运行了领先的阻塞查询，并与他们一起工作，以确保安全地杀死。

它很可能是复制本身踩到的(我以前也遇到过这种情况)，您需要终止复制过程。然后，SSMS发布属性窗口应该被解锁，并完成对项目的更改保存。之后，您可能需要重新初始化订阅服务器，以确保数据是一致的。但是，首先从我上面的建议开始，确定是什么导致阻塞查询。