【问题标题】:SQL Transaction Log Shipping fails to restore database to standbySQL 事务日志传送无法将数据库恢复到备用数据库
【发布时间】:2016-04-25 22:19:13
【问题描述】:

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

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

这里是恢复作业的日志。

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

步骤 ID 1 服务器 HERA 作业名称 LSRestore_IRIS_WebStock 步骤 名称 日志传送恢复日志作业步骤。时长 00:00:04 Sql 严重性 0 Sql 消息 ID 0 操作员已通过电子邮件发送操作员网络发送
已尝试操作员分页重试 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”、文件“WebStock_log”处理了 1 页 1.(.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 跳过日志备份文件 'E:\ShippingLogs\WebStock\WebStock_20160425033000.trn' 用于辅助 数据库“WebStock”,因为无法验证文件。 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 跳过日志备份 文件“E:\ShippingLogs\WebStock\WebStock_20160425034500.trn” 辅助数据库“WebStock”,因为无法验证该文件。 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_20160425040000.trn' 到二级 数据库'WebStock'。(Microsoft.SqlServer.Management.LogShipp

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

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

【问题讨论】:

  • 你使用的恢复模式是什么,你也可以分享这个命令的输出(RESTORE VERIFYONLY FROM DISK = 'your log file '; )你得到这个错误的日志(Could not apply log backup file 'E:\ShippingLogs\WebStock\WebStock_20160425033000.trn
  • 我们向 Microsoft 提出了有关此问题的票证,并被建议应用累积更新。 support.microsoft.com/en-au/help/4058700/… 我们将在 2014 年申请 SP3。

标签: sql-server database sql-server-2014 log-shipping


【解决方案1】:

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

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

这都是关于 LSN 的

LSN 或日志序列号是面包屑的踪迹 允许 SQL Server 中的任何恢复进程知道 要应用的交易。所有恢复过程都需要发生在 此特定顺序以确保从 事务日志和日志备份文件以这样的方式,它们是 最初应用于主数据库。

【讨论】:

    【解决方案2】:

    来自dataavail

    此备份集中的日志从 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'})。这只是一条信息性消息。无需用户操作。

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

    解决办法:

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

    【讨论】:

      猜你喜欢
      • 2011-01-29
      • 1970-01-01
      • 1970-01-01
      • 2013-09-03
      • 1970-01-01
      • 2022-09-30
      • 1970-01-01
      • 2014-07-09
      • 2019-07-13
      相关资源
      最近更新 更多