SQL Server数据库处于RESTORING状态无法删除？完整排查与解决指南

数据库状态死死卡在“正在恢复”，执行DROP DATABASE直接报错，管理工具里删除按钮也是灰色的——碰上这种情况的运维应该不少。不管你是备份还原到一半手滑取消了，还是日志传送、镜像同步出问题之后想把那个副本彻底清掉，最后都会撞到同一个坎上：SQL Server就是不让删。这篇文章我把整个场景完整过一遍，包括为什么删不掉、是先查恢复会话还是先杀连接、TSQL要怎么一步步处理，以及AlwaysOn可用性组、数据库镜像、日志传送这些高可用架构下删除顺序有什么讲究。内容全部来自实际维护里的操作经验，照着走能少踩不少坑。

1. 先搞清楚：数据库为什么赖在“正在恢复”不走

1.1 现象描述：你会遇到哪些具体情况

常见的报错画面大概是这样的。你用SSMS选中那个数据库，右键删除，弹窗提示“数据库正在还原，因此不能删除”；或者执行下面的语句，直接给你抛个错误：

USE master; GO DROP DATABASE [YourDB]; GO

错误消息一般类似“Database 'YourDB' is in transition”，或者“无法删除数据库 'YourDB'，因为它正在还原中”。如果你用下面这条语句去看状态，会看到state_desc的值是RESTORING：

SELECT name, state_desc, recovery_model_desc FROM sys.databases WHERE name = N'YourDB';

这里要说明一点：state_desc显示RESTORING不代表数据库真的还在执行还原操作。它更像是数据库元数据里的一个“状态标记”，表示这个库当前处于恢复过程中的某个阶段，不允许用户访问，也不允许被删除。搞清楚这一点，后面排查方向就不会乱。

1.2 为什么SQL Server要这样锁住数据库

说白了这是SQL Server自我保护的一种机制。数据库正在做还原或者恢复时，数据文件、日志文件都处于一个“不完全一致”的状态，如果这时候允许你把库删了，文件句柄、数据页缓存、元数据引用就会变成一笔糊涂账，严重的话整个实例都可能出问题。

你可以把它类比成装修队正在里面干活，你这时候不能直接把墙给拆了，不然楼上楼下都会受牵连。SQL Server的做法就是先给你拦住，等装修结束或者明确中断之后，你再去拆。

所以，要删除一个处于RESTORING状态的数据库，本质上只有两条路：第一条，让恢复流程正常走完，数据库自动回到ONLINE，然后再正常DROP；第二条，中断正在进行的恢复流程，让数据库进入一个可以删除的中间状态，再DROP。绝大多数情况下我们走的是第二条路，因为等它“自动走完”往往要等很久，而且很多时候恢复流程本身已经卡死了，根本走不完。

2. 动手之前：三条铁律先把现场稳住

2.1 搞清楚是谁导致了这个状态

这是最容易被忽略的一步。不要一看到RESTORING就直接上手KILL进程，先判断这个状态是怎么来的。常见的来源有三个：

• 你正在手动执行RESTORE DATABASE ... WITH NORECOVERY，数据库进入RESTORING，准备继续还原后续日志备份。
• 数据库镜像或AlwaysOn可用性组里，辅助副本正在应用主库发过来的日志，状态天然就是RESTORING。
• 日志传送（Log Shipping）配置中，辅助库在还原日志时也会处于RESTORING。

如果是第三种和第二种，你直接KILL恢复会话反而会把高可用链路搞乱，必须先解除主从关系，再做删除。

2.2 备份需求先确认，别把唯一副本斩了

这个提醒很关键。一个正在RESTORING状态的库，可能包含还没做完的完整备份还原链。如果你手头只有这一个库、没有其他可用的备份文件，先别急着删，确认一下备份文件还在不在，恢复任务还要不要继续。真把唯一的恢复源删了，后面想重建就是大工程。

2.3 分清“正在恢复”和“恢复挂起”

RESTORING和RECOVERY_PENDING是两个状态，处理方式不一样。

RECOVERY_PENDING表示数据库已经不在执行恢复操作，但是恢复流程没有正常完成，SQL Server认为这个库当前不能启动。这种状态下DROP DATABASE往往可以直接成功，不需要杀进程。而RESTORING通常意味着有恢复线程在跑，或者恢复操作被中断后没有完整退出。

判断方法还是那句SQL：

SELECT name, state_desc FROM sys.databases WHERE name = N'YourDB';

看到RECOVERY_PENDING，你直接DROP基本能过；看到RESTORING，继续往下看恢复会话的处理。

3. 常规解法：找到恢复会话，踢掉再删除

3.1 先查有没有正在执行的RESTORE操作

如果数据库正在还原过程中，sys.dm_exec_requests里面会有一条command为RESTORE DATABASE或者RESTORE LOG的记录。用这条SQL找出来：

SELECT r.session_id AS SPID, r.command, r.percent_complete, r.start_time, st.text AS SQLText FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st WHERE r.command LIKE 'RESTORE%';

注意这里的percent_complete列，如果它一直在变化，说明还原还在正常推进；如果长时间不动，大概率是卡住了。对于卡住的恢复操作，杀掉对应SPID会很干净。

如果这个查询没结果，也不要急着认定没有恢复任务。有可能恢复会话已经消失，但数据库状态在超时或异常中断时没有正常更新，留下了一个“僵尸”RESTORING状态。这种情况可以看下面3.2节处理。

3.2 杀掉恢复会话

确定SPID之后，执行：

KILL 52;

把52换成你自己查到的SPID。杀掉恢复会话之后，正在执行的RESTORE会回滚，数据库状态会发生变化，可能是RECOVERY_PENDING，也可能停留在RESTORING。多等几秒，再查一下状态：

SELECT name, state_desc FROM sys.databases WHERE name = N'YourDB';

如果变成RECOVERY_PENDING，这在删除场景下反而是好状态，直接跳过去执行DROP DATABASE。

3.3 确认状态后执行DROP

状态从RESTORING切换出来之后，执行删除：

USE master; GO DROP DATABASE [YourDB]; GO

如果一次不成功，报的是“数据库正在使用”类似信息，说明还有连接占着库，先看第3.4节杀连接。

3.4 杀掉所有占用目标库的连接

DROP DATABASE报“database is in use”，在删除正常数据库时也常见。可以先把所有连到目标库的会话一次性清掉：

DECLARE @kill_sql NVARCHAR(MAX) = N''; SELECT @kill_sql = @kill_sql + 'KILL ' + CAST(session_id AS NVARCHAR(10)) + ';' FROM sys.dm_exec_sessions WHERE database_id = DB_ID(N'YourDB'); EXEC sp_executesql @kill_sql;

注意这里只会杀掉用户会话，不会杀系统会话，所以比较安全。执行完之后再跑一次DROP DATABASE，大多能通过。

提示：杀连接之前通知一下应用侧同行，别在别人正跑着批量任务时突然把会话断了。这种操作在生产库上做，影响是实打实的。

4. 进阶解法：离线、单用户、物理文件与残留清理

4.1 先SET OFFLINE再删除

如果杀掉恢复会话之后状态还是很顽固，用一个组合拳：先把库离线，再删除。

USE master; GO ALTER DATABASE [YourDB] SET OFFLINE WITH ROLLBACK IMMEDIATE; GO DROP DATABASE [YourDB]; GO

WITH ROLLBACK IMMEDIATE会把库上的活动事务全部回滚并断开连接，这样SQL Server就可以把数据库切换到OFFLINE状态。离线之后数据库不再被恢复线程引用，DROP的阻力会小很多。

不过要注意，如果库状态还是RESTORING，且恢复线程还活着，这个ALTER也可能被阻塞。所以正确的顺序通常是先KILL恢复会话，等状态松动了再执行上面的语句。

4.2 用SINGLE_USER模式把连接赶走

另一个思路是把数据库切成单用户模式，强制把其他连接断开：

USE master; GO ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; GO DROP DATABASE [YourDB]; GO

单用户模式下，只有当前会话能访问这个库，其他连接都会被拒掉，DROP的阻塞条件就没了。这个操作比逐个KILL连接更省事，但要注意别把自己当前会话也关了——执行ALTER的会话要保持存在。

4.3 物理文件残留的处理

大多数时候，DROP DATABASE成功后，对应的.mdf和.ldf文件会被自动删除。不过总有些意外，比如杀毒软件扫描占用文件句柄、备份软件挂着文件快照、或者文件被手动改过路径，导致数据文件删不掉。

可以先确认文件路径：

SELECT physical_name FROM sys.master_files WHERE database_id = DB_ID(N'YourDB');

如果库已经从系统里消失，但文件还在磁盘上，检查是否有进程占用后手动删除。如果目录确实被SQL Server进程锁住，可以用系统命令工具配合处理，比如利用xp_cmdshell删除（如果实例开启了的话）：

EXEC xp_cmdshell 'DEL "D:\Data\YourDB.mdf"'; GO

没开启xp_cmdshell的话，用管理员权限的CMD手动删也可以。文件删不掉时，优先重启SQL Server服务再删，比在运行状态里跟文件句柄死磕省事得多。

4.4 系统目录残留怎么处理

有一类更麻烦的情况：文件已经被手动删了，或者数据库从系统目录里消失但文件还在，总之sys.databases里残留了一条指向不存在文件的记录，导致实例启动时报错或者DBCC检查不干净。

这种问题的根因是之前的操作没有走正规DROP流程。正规解法是尽量让SQL Server把元数据清理干净。如果数据库文件还在，可以尝试在单用户模式下重新启动它，然后正常DROP。如果文件已经没了，操作空间就很小，一般不建议去手搓系统表，风险极大。真要处理这种情况，备份一下master数据库，做好实例级别的快照，再考虑低层手段。

注意：直接改sys.databases或系统目录视图是最后手段，代价是实例可能再也起不来。能通过附加文件、还原备份来恢复元数据的，就优先走正常SQL路径。

5. 高可用场景下的删除流程

5.1 数据库镜像会话里，先断开镜像再删

镜像会话存在时，镜像端的数据库长期处于RESTORING状态，这是设计如此，因为镜像在持续应用主库发来的日志块。你以为它“卡住”了，其实它是正常的。这种状态下直接在镜像端执行DROP DATABASE，通常会被拒。

正确顺序是在主库端断开镜像会话：

ALTER DATABASE [YourDB] SET PARTNER OFF; GO

这条命令会在主库上终止镜像关系。主库会回到独立状态，镜像端数据库因为失去了同步源，状态会变化，这时再在镜像端执行DROP DATABASE就能成功。如果你不需要保留主库，也可以之后在主库执行删除。

5.2 AlwaysOn可用性组：先摘出组再删副本

AlwaysOn比镜像更麻烦一点，因为可用性组里有主副本和辅助副本的地位关系。辅助副本上的数据库为了回放日志，状态在sys.databases里显示为RESTORING，这同样是正常状态。

错误做法是直接连到辅助副本去KILL恢复进程或者DROP，那样会破坏同步。正确做法先处理可用性组层面的配置，把目标数据库从可用性组移除。这一步可以在主副本上执行：

ALTER AVAILABILITY GROUP [AG1] REMOVE DATABASE [YourDB]; GO

或者使用管理工具里的可用性组向导来移除。移除之后，辅助副本上的数据库不再被同步流程绑定，状态就不会一直维持在RESTORING了。接下来再在各个副本上分别执行：

DROP DATABASE [YourDB]; GO

如果某个辅助副本上的库状态还是RESTORING，用第3节的KILL流程处理掉恢复会话，再DROP。

5.3 日志传送：先清配置再删辅助库

日志传送的辅助库在应用日志备份时，也会处于RESTORING状态。想把它删掉，同样先断配置链。

在主库所在实例上，执行存储过程删除主库侧的日志传送映射：

EXEC msdb.dbo.sp_delete_log_shipping_primary_secondary @primary_database = N'PrimaryDB', @secondary_server = N'SecondaryServer', @secondary_database = N'SecondaryDB'; GO

在辅助库所在实例上，删除辅助库侧的日志传送记录：

EXEC msdb.dbo.sp_delete_log_shipping_secondary_database @secondary_database = N'SecondaryDB'; GO

然后回到辅助库上执行DROP DATABASE。如果这个时候库里还有正在跑的恢复作业，可以先停掉日志传送的还原作业再删，避免作业在你删库的同时又启动一把恢复。

6. 常见问题速查与实操心得

6.1 一个排查脚本组合，建议直接收藏

我在实际处理这类问题时，习惯先跑一段组合脚本，把状态、会话、文件路径一次性列出来：

USE master; GO -- 1. 查看目标库状态 SELECT name, state_desc, database_id FROM sys.databases WHERE name = N'YourDB'; -- 2. 查看是否有RESTORE会话 SELECT r.session_id, r.command, r.percent_complete, r.start_time, st.text FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st WHERE r.command LIKE 'RESTORE%'; -- 3. 查看所有连接到目标库的会话 SELECT s.session_id, s.login_name, s.status, s.database_id FROM sys.dm_exec_sessions s WHERE s.database_id = DB_ID(N'YourDB');

跑完这三段，大部分情况的定位就清楚了。之后再决定是杀恢复会话、杀用户连接，还是先处理高可用关系。

6.2 典型错误对照表

6.3 我踩过的坑和几点经验

第一，KILL恢复会话之后不要立刻DROP。等数据库状态稳定下来再删，这个“等”可能只需要几秒钟，但跳过这几秒往往就会遇到“正在转换中”的报错。稍安勿躁，多看两遍sys.databases。

第二，如果库是AlwaysOn的辅助副本并且状态显示RESTORING，不要一上来就KILL。同步机制把它压成RESTORING是正常的，你KILL它只是打断同步，反而把可用性组状态搞乱。一定要先在AG层面移除数据库。

第三，对于生产环境，删除前先检查一下这个库是不是某个备份链的起点，以及删掉之后是否有依赖这个库的作业、报警、维护计划。光看数据库状态不解决业务问题，真正出事的是你删完了，别人第二天过来说“那个库的备份怎么没了”。

第四，DROP DATABASE成功后，记得观察几分钟，确认实例的错误日志里没有新的异常。尤其是处理过恢复会话的库，有些残留的锁和任务要一点时间才能清掉。

第五，如果你所在的团队对这类操作有变更流程，不要因为库“卡住”就跳过变更申请。删除一个数据库的元数据和文件是不可逆操作，宁可多走一步审批流程，也别事后写一堆解释说明。

这个场景的处理核心其实就一句话：先判断这个RESTORING状态是正常同步流程导致的，还是异常中断留下的，然后分别走对应的解除路线，最后再DROP。顺序对了，大部分情况都能顺利解决。