简体   繁体   English

数据库已经完全恢复。 RESTORE DATABASE 异常终止

[英]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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM