我备份了一个数据库:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

然后试图恢复它:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

现在数据库处于还原状态。

有些人推测,这是因为备份中没有日志文件,需要使用以下方法前滚:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

当然,这是行不通的:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

在灾难性的情况下,你想要的是一个无法工作的恢复。


备份包含数据文件和日志文件:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

当前回答

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

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

Drop database *dbname*

其他回答

请使用以下命令解决此问题

RESTORE DATABASE [DatabaseName] WITH RECOVERY

我有一个。在我的数据库名称中,查询没有工作,因为(在'.'附近说不正确的语法)然后我意识到我需要一个括号的名称:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

默认情况下,每个RESTORE DATABASE都带有恢复设置。 “NORECOVERY”选项,基本上告诉SQL Server数据库正在等待更多的恢复文件(可能是一个DIFF文件和LOG文件,如果可能的话,可能包括尾日志备份文件)。 “RECOVERY”选项,完成所有事务,让数据库准备好执行事务。

So:

如果您的数据库设置为SIMPLE恢复模式,那么当您有一个DIFF备份时,您只能执行带NORECOVERY选项的完全恢复。在SIMPLE恢复模型数据库中不允许LOG备份。 否则,如果数据库设置为FULL或BULK-LOGGED恢复模型,则可以执行FULL恢复,然后执行NORECOVERYoption,然后执行DIFF,然后执行NORECOVERY,最后使用recovery选项执行LOG恢复。

记住,最后一个恢复查询必须有恢复选项。这可能是一种明确的方式,也可能不是。在T-SQL方面,情况如下:

1.

 USE [master]
    GO
    RESTORE DATABASE Database_name 
    FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, 
    RECOVERY -- This option could be omitted.
    GO

必须谨慎使用WITH REPLACE选项,因为它可能导致数据丢失

或者,如果执行FULL和DIFF备份,则可以使用此选项

   USE [master]
    GO
    RESTORE DATABASE Database_name
      FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
       NOUNLOAD,NORECOVERY
    GO
    RESTORE DATABASE Database_name
      FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
     NOUNLOAD, RECOVERY
    GO

 2. USE [master]
    GO
   -- Perform a Tail-Log backup, if possible. 
   BACKUP LOG Database_name
   GO
   -- Restoring a FULL backup
   RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
     NOUNLOAD,NORECOVERY
  GO 
  -- Restore the last DIFF backup
  RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1,
     NORECOVERY,NOUNLOAD
  GO
  -- Restore a Log backup
  RESTORE LOG Database_name
    FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2,
    RECOVERY, NOUNLOAD
  GO

当然,您可以使用STATS = 10选项执行恢复,该选项告诉SQL Server每完成10%就报告一次。

如果您愿意,您可以观察过程或基于实时查询的恢复。 遵循:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

希望这对你有所帮助。

在使用SQL server management studio恢复数据库时遇到了类似的问题,它陷入了恢复模式。经过几个小时的问题跟踪,下面的查询对我有用。下面的查询将数据库从现有备份恢复到以前的状态。我相信,关键在于.mdf和.log文件在同一个目录下。

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

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

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