SQL Server日志传送作业报错：数据库已完全恢复 还原异常终止

错误码3153的触发逻辑非常明确：SQL Server不允许对已经完成恢复流程、处于在线可用状态的数据库，执行RESTORE WITH STANDBY/NORECOVERY操作。
结合贴出的作业脚本，故障触发的具体路径是：

• 脚本Step4调用的dbo.sp_DatabaseRestore社区存储过程默认逻辑存在分支：当@ContinueLogs=1但扫描到日志目录下没有新的可还原事务日志、或待还原日志序列不连续时，部分版本会自动执行RESTORE WITH RECOVERY把数据库拉到在线可读写状态，而不是按预期保持NORECOVERY等待Step5切Standby。
• 上周末作业运行时大概率出现了日志文件拉取异常（比如Step1映射网络盘失败、Step2移动trn文件时目录为空、working目录残留旧日志导致日志链识别错误），触发了上述存储过程的自动恢复逻辑，Step4执行完时数据库已经处于ONLINE状态，Step5再执行Standby切换就直接报3153错误。
• 脚本存在额外隐患：Step4中硬编码了2021年3月5日的全量备份路径，一旦该路径下的全量备份被清理、或存储过程校验全备有效性失败，也会触发自动恢复分支。

在master库执行以下SQL，确认数据库当前状态：

SELECT 
    name,
    state_desc,
    is_in_standby,
    is_read_only,
    (SELECT TOP 1 last_log_backup_lsn FROM sys.database_recovery_status WHERE database_id = db_id('<DatabaseName>')) AS last_restore_lsn
FROM sys.databases
WHERE name = '<DatabaseName>'

如果返回结果中state_desc = ONLINE、is_in_standby = 0，即可确认数据库已经脱离日志传送链路，被完全恢复。
同时查看对应SQL作业的Step4历史日志，能找到类似Recovery completed for database <DatabaseName>的记录，对应自动恢复的触发时间点。

临时恢复业务 #

SQL Server存在硬限制：一旦数据库执行过WITH RECOVERY完成恢复，就无法继续接续之前的日志传送链路，必须重新初始化Standby副本：

1. 确认本地只读副本无业务写入后，删除异常状态的目标数据库。
2. 从供应商侧获取最新的全量备份，执行全量还原时加NORECOVERY参数。
3. 按LSN顺序，还原全量备份后所有未应用的事务日志，所有日志还原操作均加NORECOVERY参数，禁止执行恢复操作。
4. 所有日志还原完成后，手动执行Step5的Standby切换命令：

   RESTORE DATABASE [<DatabaseName>] 
   WITH STANDBY = N'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\<DatabaseName>_RollBackUndo.bak'
   

5. 确认数据库状态变为STANDBY/只读，验证二级系统查询访问正常，即可恢复业务。

脚本永久加固 #

修复现有自动化作业的逻辑漏洞，避免故障重复触发：

• 修改Step4的存储过程调用参数，显式添加强制不恢复的参数（不同版本sp_DatabaseRestore对应参数为@NoRecovery = 1或@RunRecovery = 0，需匹配当前使用的存储过程版本参数定义），确保无论是否存在待还原日志，Step4执行结束后数据库始终保持RESTORING状态，禁止自动触发RECOVERY。
• 在Step4和Step5之间增加状态校验逻辑：Step4执行完成后立刻查询sys.databases，如果目标库状态不是RESTORING，直接抛出错误终止作业，避免无效执行Step5。
• 修复文件操作逻辑：Step1映射网络盘后增加存在性校验，确认y盘映射成功再往下执行；Step2移动trn文件时增加文件存在判断，无新日志时直接正常退出作业不要触发异常分支；Step6移动已应用日志时增加错误捕获，移动失败立刻终止作业，避免旧日志残留到下一次作业运行。
• 去掉Step4中硬编码的2021年全量备份路径，改为动态扫描备份目录获取最新的有效全量备份路径，避免全量备份被清理后触发存储过程异常。

内容的提问来源于stack exchange，提问作者Aeden Maddok