使SQL Server数据库脱机时的极端等待时间

我试图在我的开发数据库上执行一些离线维护(从实时备份恢复开发数据库)，但是通过SQL Server Management Studio执行的“脱机”命令执行得非常慢——大约30分钟以上。我只是在我的智慧的尽头，我似乎找不到任何参考网上可能导致速度问题，或如何解决它。

一些站点建议，打开到数据库的连接会导致这种放缓，但使用此数据库的唯一应用程序是我的开发机器的IIS实例，并且服务已停止—没有更多打开的连接。

是什么导致了这种减速，我能做些什么来加速它?

当前回答

在我的情况下，在执行这个操作之前，我已经在DB中查看了一些表。我的用户帐户持有到SSMS中此DB的活动连接。一旦我从SSMS中的服务器断开连接(使“使数据库脱机”对话框打开)，操作成功。

其他回答

您是否有任何连接到此DB的打开的SQL Server Management Studio窗口?

将其置于单用户模式，然后再试一次。

很可能从某个地方连接到DB(一个罕见的例子:异步统计更新)

要查找连接，请使用sys.sysprocesses

USE master
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('MyDB')

要强制断开连接，请使用ROLLBACK IMMEDIATE

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

对我来说，我只需要进入Job Activity Monitor并停止正在处理的两件事情。然后它马上就下线了。就我而言，我知道这两个过程是什么，也知道停止它们是可以的。

经过一些额外的搜索(受到gbn的答案和u07ch对KMike答案的评论启发的新搜索词)，我发现了这个，在2秒内成功完成:

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(更新)

当仍然出现以下错误时，您可以根据这篇博客文章的启发进行修复:

ALTER DATABASE失败，因为无法在数据库'dbname'上放置锁。

您可以运行以下命令来找出谁在锁定您的数据库:

EXEC sp_who2

并使用你在以下命令中找到的任何SPID:

KILL <SPID>

然后再次运行ALTER DATABASE命令。现在应该可以工作了。

以我为例，在等待了这么久之后，我没有耐心，干脆关闭了管理工作室。退出前，显示成功消息，db is offline。可以重命名这些文件。

推荐文章