SSMS，特别是从您自己的桌面远程运行而不是直接在数据库服务器中运行时，可能是分离数据库时出现长时间延迟的原因之一。由于某些原因，SSMS可能无法断开与数据库的任何现有“连接”。

当我们直接从数据库服务器本身执行时，我们发现这个过程几乎是即时的。事实上，它杀死了我自己的桌面SSMS会话的尝试，它“接管”并分离数据库。

这里建议的其他方法都不起作用。

谢谢

任何时候遇到这种情况，您都应该考虑您的事务日志。带有rollback immediate的alter db语句表明是这种情况。看看这个:http://msdn.microsoft.com/en-us/library/ms189085.aspx

钻研检查点等等。您需要决定日志中的事务是否值得保存，然后选择相应的模式来运行数据库。真的没有理由让你不得不等待，但也没有理由让你失去数据——你可以两者兼得。

执行存储过程 sp_who2

这将允许您查看是否有任何阻塞锁..杀死他们应该修复它。

在SSMS中，将数据库设置为只读，然后返回。连接将被关闭，从而释放锁。

在我的例子中，有一个网站打开了到数据库的连接。这个方法很简单:

右键单击数据库-> Properties -> Options “数据库只读”设置为“True” 在弹出的对话框中单击“是”，警告SQL Server将关闭与数据库的所有连接。 重新打开选项并关闭只读 现在尝试重命名数据库或使其脱机。

在我的例子中，数据库与旧的Sharepoint安装有关。在服务器管理器中停止和禁用相关服务“解除”已经运行了40分钟的脱机操作，并立即完成。

您可能希望检查当前是否有任何服务正在使用该数据库。

下次，在“脱机”对话框中，记得选中“删除所有活动连接”复选框。我也在本地机器上的SQL_EXPRESS上，没有连接，但除非我选中该复选框，否则会出现这种减速。