[英]The database is already fully recovered. RESTORE DATABASE is terminating abnormally
I've recently inherited the responsibilities of a DBA without the benefit of having any DBA training.我最近继承了 DBA 的职责,却没有接受任何 DBA 培训。 We have a database (omitted name for security reasons) that is essentially setup to run in Standby mode to be used as a read-only database for secondary systems.
我们有一个数据库(出于安全原因省略了名称),它基本上设置为在待机模式下运行,用作辅助系统的只读数据库。 This database is updated by log shipping from a vendor of ours so we essentially have an almost up-to-date copy of their database at all times.
该数据库通过我们供应商的日志传送进行更新,因此我们基本上始终拥有他们数据库的几乎最新副本。
However, over the weekend the automated process started failing on step 5 of the procedure.然而,在周末,自动化过程在程序的第 5 步开始失败。 We are getting the error message "The database is already fully recovered. [SQLSTATE 42000] (Error 3153) RESTORE DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed."
我们收到错误消息“数据库已完全恢复。[SQLSTATE 42000](错误 3153)RESTORE DATABASE 异常终止。[SQLSTATE 42000](错误 3013)。步骤失败。”
I need help to understand what is failing and how I can fix it.我需要帮助来了解失败的原因以及如何解决它。 Any help you can provide would be greatly appreciated.
您能提供的任何帮助将不胜感激。 Below is a script of the automated job broken out step-by-step.
下面是逐步分解的自动化作业的脚本。
/* Step 1 - Map Network Drive */
BEGIN
EXEC xp_cmdshell 'net use /persistent:no';
EXEC xp_cmdshell 'net use * /d /Y';
EXEC xp_cmdshell 'net use y: \\<FtpServer>\<folder> /user:<UserName> "<Password>"';
END
/* Step 2 - MOVE Files from network share to working folder */
BEGIN
EXEC xp_cmdshell 'if exist y:\*.trn move y:\*.trn y:\working';
END
/* Step 3 - Kill any exiting connections to the database */
BEGIN
USE [master];
DECLARE @kill varchar(8000) = '';
SELECT @kill = @kill + 'kill ' + CONVERT(varchar(5), session_id) + ';'
FROM sys.dm_exec_sessions
WHERE database_id = db_id('<DatabaseName>')
EXEC(@kill);
END
/* Step 4 - Restore Transaction Logs */
BEGIN
EXEC dbo.sp_DatabaseRestore
@Database = '<DatabaseName>',
@BackupPathFull = 'G:\Base Backup\TWHSQL2014FCluster$TWHSQL2014F_<DatabaseName>_FULL_20210305_213505\',
@BackupPathLog = 'y:\working\',
@RestoreDatabaseName = '<DatabaseName>',
@ContinueLogs = 1,
@RunRecovery = 0;
END
/* Step 5 - Change DB to STANDBY mode */
BEGIN
Restore Database [<DatabaseName>] With Standby = N'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\<DatabaseName>_RollBackUndo.bak'
END
/* Step 6 - MOVE Applied Logs to archive */
BEGIN
EXEC xp_cmdshell 'move y:\working\*.* y:\archived';
END
/* Step 7 - Archive Undo File */
BEGIN
EXEC xp_cmdshell 'if exist "C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\*.bak" copy "C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\*.bak" "G:\LogShipping Undo File" /y';
END
This problem has been resolved.这个问题已被解决。 The cause of the problem was that a log file did not get restored, but did get moved to the archived folder and so we were attempting to skip a log file in the restoration process.
问题的原因是日志文件没有恢复,但确实被移动到存档文件夹,因此我们试图在恢复过程中跳过日志文件。 Still, I would have expected the error message to state something akin to the log file doesn't have the correct LSN value or something else to indicate that there was a log missing.
尽管如此,我仍然希望错误消息指出类似于日志文件的内容没有正确的 LSN 值或其他内容来表明缺少日志。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.