恢复数据库时遇到无法独占错误

　--运行以下脚本，清除当前的所有进程 

declare @sql as varchar(20), @spid as int
select @spid = min(spid)  from master..sysprocesses  where dbid = db_id('<database_name>') 
and spid != @@spid  

while (@spid is not null)
begin
    print 'Killing process ' + cast(@spid as varchar) + ' ...'
    set @sql = 'kill ' + cast(@spid as varchar)
    exec (@sql)

    select 
        @spid = min(spid)  
    from 
        master..sysprocesses  
    where 
        dbid = db_id('<database_name>') 
        and spid != @@spid
end

print 'Process completed...'

症状：

　　在恢复数据库时，遇到报错：　System.Data.SqlClient.SqlError: 因为数据库正在使用，所以无法获得对数据库独占访问权。(Microsoft.SqlServer.SmoExtended)

原因分析：

　　那么，是谁独占了呢？是不是因为我们在testDB单击右键，导致这个数据库被占用了呢？

　　尝试从master数据库开始单击右键。可是，仍然遇到同样的错误。

　　运行以下脚本，查看哪些Windows进程占用了这个数据库。spid 是 SQL Server 内部为每一个连接而分配的进程编号；hostprocess则是 Windows 为应用程序分配的进程编号。

select  spid, status, hostprocess,
  login_time, last_batch, open_tran, blocked
  from master..sysprocesses
  where dbid =db_id('testDB')

　　按照常规，我们只要切换到SSMS，KILL它。例如，上图显示spid=59占用了testDB数据库。在SSMS运行脚本删除这个进程。

Kill 59

　　这个案例太奇怪了！如上所示，我们已经把使用数据库的进程（spid=59）kill掉了，在Windows任务管理器也看不到了（hostprocess=4592）。可是，我们再次在SSMS打开“还原数据库”窗口，在恢复数据库时仍然报同样的错误。

解决方案：

　　用脚本算了吧。

USE [master]
RESTORE DATABASE [testDB] FROM  DISK = N'C:MSSQLBackup estdb.bak' WITH  FILE = 14,  NOUNLOAD,  REPLACE,  STATS = 5

GO

原因分析：

　　无意中选择了“数据库”节点，然后单击“新建查询”，突然发现默认的数据库竟然就是testDB ！

　　赶紧去检查恢复操作时使用的连接。真的是这个原因。

　　罪魁祸首就是这个“默认数据库”。

　　把“默认数据库”指定为master，退出SSMS。重新登录，再做恢复，OK。

转自：http://blog.51cto.com/jimshu/1625445