好吧，我有类似的问题，就像在Pauk的情况下一样，这是由服务器在恢复时耗尽磁盘空间引起的，因此导致了永久恢复状态。 如何在不停止SQL Server服务的情况下结束此状态?

我找到了一个解决方案:)

Drop database *dbname*

先检查并运行SQL代理服务。 使用以下T-SQL: 选择文件名 从master.sys.sysaltfiles WHERE dbid = DB_ID('db_name'); 连续使用T-SQL: 从磁盘恢复数据库= 'DB_path' 与 重启,取代;

希望这对你有所帮助!

你可以这样做:

停止服务(MSSQLSERVER); 重命名或删除数据库和日志文件(C:\Program files \Microsoft SQL Server\MSSQL.1\MSSQL\Data…)或任何你有文件的地方; 启动服务(MSSQLSERVER); 删除有问题的数据库; 重新恢复数据库。

这是一个老问题，SQL Server一直在出现，即使是最新的2019版本!我不知道为什么微软让这种痛苦持续了这么长时间，并允许他们的MSSQL引擎继续以这种方式表现。尽管如此，对于那些尝试过RESTORE DATABASE WITH RECOVERY的人，我建议另一种可能的解决方案 选项，但它仍然不起作用。

登录到服务器本身，并在实际的数据库服务器上启动默认的SSMS程序。接下来进入“恢复”数据库并删除它。完成了。问题消失了。如果需要保留它，复制MDF文件并重命名它，然后将其附加为一个新数据库。在SQL Server 2008 R2上为我工作。

执行RESTORE DATABASE/RESTORE LOG命令时，默认使用WITH RECOVERY选项。如果你被困在“恢复”过程中，你可以通过执行以下命令将数据库恢复到在线状态:

RESTORE DATABASE YourDB WITH RECOVERY
GO

如果需要恢复多个文件，CLI命令分别需要WITH NORECOVERY和WITH RECOVERY -只有命令中的最后一个文件需要WITH RECOVERY才能使数据库恢复在线:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

你也可以使用SQL Server Management Studio向导:

也有虚拟恢复过程，但你必须使用第三方解决方案。通常，您可以使用数据库备份作为实时在线数据库。ApexSQL和Idera都有自己的解决方案。由SQL Hammer审查关于ApexSQL恢复。如果要处理大量备份，虚拟恢复是一个很好的解决方案。恢复过程要快得多，还可以节省磁盘驱动器上的大量空间。你可以看看这里的信息图进行一些比较。

当我在事件日志中也收到TCP错误时，我遇到了这个问题…

用sql删除数据库或在管理器“delete”中右键单击它 然后再恢复。

实际上我已经开始默认这样做了。脚本数据库删除，重新创建，然后恢复。