5

我已经在 2 个 SQL 2014 服务器之间设置了事务日志传送,一切似乎都设置正确,但是当恢复发生时,如果 .trn 真的很小,例如 7k,它似乎会失败。

不确定这是否与它有任何关系,但它是唯一不同的事情。

以下是还原作业的日志。

日期 25/04/2016 22:59:24 记录作业历史记录 (LSRestore_IRIS_WebStock)

步骤 ID 1 服务器 HERA 作业名称 LSRestore_IRIS_WebStock 步骤名称 日志传送恢复日志作业步骤。持续时间 00:00:04 Sql Severity 0 Sql Message ID 0 Operator Emailed Operator Net sent
Operator Paged Retries Attempted 0

消息 2016-04-25 22:59:28.71 错误:无法将日志备份文件“E:\ShippingLogs\WebStock\WebStock_20160425033000.trn”应用到辅助数据库“WebStock”。(Microsoft.SqlServer.Management.LogShipping)2016-04 -25 22:59:28.71 错误:处理数据库“WebStock”的日志时出错。如果可能,从备份中恢复。如果备份不可用,则可能需要重建日志。恢复期间发生错误,导致数据库“WebStock”(12:0) 无法重新启动。诊断恢复错误并修复它们,或从已知良好的备份中恢复。如果错误未得到纠正或未预料到,请联系技术支持。

RESTORE LOG 异常终止。为数据库“WebStock”处理了 0 页,文件 1 上的文件“WebStock”。为数据库“WebStock”处理了 1 页,文件 1 上的文件“WebStock_log”。(.Net SqlClient 数据提供者)2016-04-25 22:59: 28.71 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59:28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 跳过辅助数据库“WebStock”的日志备份文件“E:\ShippingLogs\WebStock\WebStock_20160425033000.trn”,因为该文件无法已验证。2016-04-25 22:59:28.73 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management。LogShipping) 2016-04-25 22:59:28.73 错误:ExecuteNonQuery 需要一个打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:恢复数据库访问模式时出错。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59 :28.73 错误:ExecuteScalar 需要一个打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59: 28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:无法应用日志备份文件'E:\ShippingLogs\WebStock\WebStock_20160425034500.trn' 到辅助数据库 'WebStock'。(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59: 28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 跳过辅助数据库“WebStock”的日志备份文件“E:\ShippingLogs\WebStock\WebStock_20160425034500.trn”,因为该文件不能已验证。2016-04-25 22:59:28.73 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59:28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:恢复数据库访问模式时出错。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59 :28.73 错误:ExecuteScalar 需要一个打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:无法记录历史记录/错误消息。(Microsoft.SqlServer.Management.LogShipping)2016-04-25 22:59: 28.73 错误:ExecuteNonQuery 需要打开且可用的连接。连接的当前状态已关闭。(System.Data)2016-04-25 22:59:28.73 错误:

如果我删除该日志并再次运行还原,它会一直工作,直到找到另一个非常小的日志。

如果日志为空,恢复会失败吗?

4

2 回答 2

0

数据可用性

此备份集中的日志从 LSN <#> 开始,它太新,无法应用于数据库

这是在各种日志传送生产场景中出现的错误。

2016-07-25 07:37:12.34 * 错误:文件“C:\LS_Secondary\LogShippingDB_20160725020411.trn”太新,无法应用于辅助数据库“LogShippingDB”。(Microsoft.SqlServer.Management.LogShipping)*

2016-07-25 07:37:12.34 * 错误:此备份集中的日志从 LSN 79000000014400001 开始,该数据太新,无法应用于数据库。可以还原包含 LSN 79000000011200001 的早期日志备份。RESTORE LOG 异常终止。(.Net SqlClient 数据提供程序) *

日志传送基于每个事务备份日志与之前的事务日志备份形成一个链的概念。如果我们尝试跳过任何日志备份,则会遇到上述错误。要查找丢失的备份,我们可以使用 MSDB 备份历史表或 ERRORLOG 文件。它们都包含有关备份类型、位置等的信息。

2016-07-25 07:32:11.95 备份日志已备份。数据库:LogShippingDB,创建日期(时间):2016/07/24(21:53:30),第一个LSN:79:48:1,最后一个LSN:79:80:1,转储设备数量:1,设备信息: (FILE=1, TYPE=DISK: {'C:\LS\LogShippingDB_20160725020211.trn'})。这只是一条信息性消息。无需用户操作。

2016-07-25 07:33:11.83 备份日志已备份。数据库:LogShippingDB,创建日期(时间):2016/07/24(21:53:30),第一个LSN:79:80:1,最后一个LSN:79:112:1,转储设备数量:1,设备信息: (FILE=1, TYPE=DISK: {'C:\LS\LogShippingDB_20160725020311.trn'})。这只是一条信息性消息。无需用户操作。

2016-07-25 07:33:32.22 备份日志已备份。数据库:LogShippingDB,创建日期(时间):2016/07/24(21:53:30),第一个LSN:79:112:1,最后一个LSN:79:144:1,转储设备数量:1,设备信息: (FILE=1, TYPE=DISK: {'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\Extra.trn'})。这只是一条信息性消息。无需用户操作。

2016-07-25 07:34:11.69 备份日志已备份。数据库:LogShippingDB,创建日期(时间):2016/07/24(21:53:30),第一个LSN:79:144:1,最后一个LSN:79:176:1,转储设备数量:1,设备信息: (FILE=1, TYPE=DISK: {'C:\LS\LogShippingDB_20160725020411.trn'})。这只是一条信息性消息。无需用户操作。

我们已经突出显示了失败的日志备份。现在,我们需要及时回到过去,找出为什么之前的日志没有在辅助服务器上恢复。

解决方案:

找到丢失的日志备份并在辅助数据库中手动还原。恢复后,下一个备份将自动赶上。

于 2017-03-27T11:43:19.937 回答
0

http://sqlmag.com/database-high-availability/how-restart-failed-log-shipping-quickly

请阅读文章。还有更多内容。我想我不能在这里发布整篇文章。

一切都是关于 LSN

LSN 或日志序列号是面包屑的踪迹,它允许 SQL Server 中的任何恢复过程知道要应用的事务的顺序。所有恢复过程都需要按此特定顺序进行,以确保从事务日志和日志备份文件中读取事务,使其最初应用于主数据库。

于 2017-03-23T21:23:43.067 回答