备份事务日志时遇到 log corruption

最新推荐文章于 2024-07-23 02:33:49 发布
原创 最新推荐文章于 2024-07-23 02:33:49 发布 · 399 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库

本文分析了SQL Server中日志备份失败而完整备份成功的原因，指出日志损坏会导致日志备份失败。提供了通过更改数据库恢复模式来重建日志链的方法。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

故障描述：

备份事务日志时遇到以下错误

Backup detected log corruption in database FakeDBName. Context is FirstSector. LogFile: 2 ‘F:\SQLLOGS\XYZ\FakeDBName_Log.ldf’ VLF SeqNo: x502e VLFBase: x2ce40000 LogBlockOffset: x2d0a9000 SectorStatus: 2 LogBlock.StartLsn.SeqNo: x4ee3 LogBlock.StartLsn.Blk: x1348 Size: x200 PrevSize: x400
2009-03-06 10:00:02.61 Backup      Error: 3041, Severity: 16, State: 1.
2009-03-06 10:00:02.61 Backup      BACKUP failed to complete the command BACKUP LOG FakeDBName Check the backup application log for detailed messages.
2009-03-06 10:00:03.61 Backup      Error: 3041, Severity: 16, State: 1.


执行完整备份的时候，没有报错。



原因分析：

1. 日志备份时，需要备份自上一次日志备份以来的整个日志链。日志链中的任何log corruption都会报错，并导致日志备份失败。

2. 为何完整备份没有报错呢？因为完整备份只需要少量的事务日志。参见 http://www.mssqlmct.cn/dba/?post=203




对策：

SQL Server 没有重建事务日志链的工具和直接方法。建议重建事务日志链：

1. 停止该数据库所有的事务；

2. 执行完整备份；

3. 将数据库的恢复模式改为“简单”，此步骤将删除原来的事务日志链。如有大量缓冲区的数据未回写硬盘，请执行 checkpoint。如有必要，可收缩事务日志文件。

4. 再将数据库的恢复模式改回“完整”；

5. 执行完整备份，此步骤将重建事务日志链；

6. 可继续执行事务日志备份。




参考文献：

https://www.sqlskills.com/blogs/paul/how-can-a-log-backup-fail-but-a-full-backup-succeed/


【0250】深入分析Write-Ahead Log Fault Tolerance（WAL容错）
Postgres 数据库内核开发工程师
01-23 418
本文将详细讲解影响。
MySQL破log_记一次mysql事故恢复过程
weixin_39913648的博客
01-20 634
1、事故缘由2020年04月需要搬迁机房，将虚拟机直接挂起，在当天搬迁完后，继续运行虚拟机，发现服务没起来，mysql启动失败。2、出错日志mysql启动报错如下：/var/log/mysqld.log2020-04-20T02:27:01.161441Z 0 [Warning] Could not increase number of max_open_files to more than 50...
【DATAGUARD】物理dg配置客户端无缝切换 (八.2)--Fast-Start Failover 的配置.pdf
07-31
【DATAGUARD】物理dg配置客户端无缝切换 (八.2)--Fast-Start Failover 的配置.pdf
Data Guard Broker系列之六：Fast-Start Failover
czmmiao的专栏
10-06 506
Fast-Start Failover 基本概念 Fast-Start Failover是建立在broker基础上的一个快速故障转换的机制，通过fast-start failover可以自动检测primary的故障，然后自动的failover到预先指定的standby上面，这样可以最大化的减少故障时间，提高数 据库的可用性。 结构 Fast-Start Failover是在brok...
fast start oracle,Oracle Data Guard快速启动故障切换 - fast-start failover(FSFO)
weixin_32533375的博客
04-08 369
fast-start failover(FSFO)功能是当primary数据库Crash后，它会自动地快速执行切换standby数据库为primary数据库操作。 那么什么时候会触发fast-start failover呢？ 当数据库以正常模式(shutdown immediate/normal/transactional)关闭时，系统不会触发fast-start failover。 使用非正常...
fast start oracle,Oracle Data Guard fast-start failover配置与应用
weixin_36473811的博客
04-08 242
这个fast-start failover的功能是当primary数据库down掉后，它会自动地快速执行切换standby数据库为primary数据库操作，在实际环境中这个功能还是蛮不错的。那么何时系统才会执行fast-start failover呢？据官方文档介绍，当数据库以正常模式(shutdown immediate、shutdown normal、shutdown transactiona...
SQL Server事务日志备份，截断和缩减操作
culuo4781的博客
07-21 5457
In this article, we will cover SQL Server Transaction log backups, truncate and shrink operations with an overview and examples covering everything discussed 在本文中，我们将介绍SQL Server事务日志备份，截断和收缩操作，并...
如何使用损坏或删除SQL Server事务日志文件重建数据库
culuo4781的博客
07-29 1985
This is the last article, but not the least one, in the SQL Server Transaction Log series. In this series of articles (see the TOC below), we described the Transaction Log concept from four differ...
oracle日志文件大全
12-04
- 触发机制：日志缓冲区满三分之一、超过一兆的变化记录、事务提交时触发日志写入。 ##### 2. Archivelog Files（归档日志） - **定义**：归档日志是在归档模式下保存的已满的联机重做日志文件的副本，用于长期...
ORACLE failover 恢复
07-07
oracle failover 切换后 恢复 DG
oracle DG(搭建+swithover+failover(flashback恢复）+broker(fsfo)
02-17
包括：dg 环境搭建，dg swithover和failover以及failover后利用flashback恢复，dg broker 配置和fsfo 配置
【DATAGUARD】物理dg配置客户端无缝切换 (八.2)--Fast-Start Failover 的配置
小麦苗DBA宝典
09-29 1651
【DATAGUARD】物理dg配置客户端无缝切换 (八.2)--Fast-Start Failover 的配置 一.1  BLOG文档结构图       一.2  前言部分   一.2.1  导读 各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~： ① Data Guard Broker 的配置 ② Fast-Start
Oracle DG主库失败Failover参考
weixin_35861708的博客
07-23 234
Oracle DG（DataGuard）中，角色转换包括Switchover和Failover两种。Switchover相对比较简单和常见，这里不做赘述。这里，本文仅就Failover及然后将Failed Primary Database转换为Physical Standby Database的操作和过程做介绍和说明。 一...
Oracle DG Failover 操作
leo__1990的博客
06-10 2211
1 在主库端模拟数据库意外宕机 主库操作 [oracle@localhost ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.4.0 Production on Wed May 10 11:53:25 2017 Copyright (c) 1982, 2013, Oracle. All rights reserved. SQL> con...
oracle dg failover
zzpabcd的博客
04-14 329
Standby:Dev:Prod:手动操作Failover:–error。
Oracle RAC failover 测试 连接时故障转移
fsfsdfsdw的博客
02-02 518
Oracle RAC failover 测试 连接时故障转移
oracle+故障切换,oracle 11g dg broker 开启fast-start failover自动故障切换
weixin_36241447的博客
04-03 215
一.首先保证主从数据库的闪回数据库功能以及强制归档都打开，如下保证都为yesSQL> select flashback_on,force_logging from v$database;FLASHBACK_ON FOR------------------ ---NO NO1.1开启闪回数据库SQL> ALTER SYSTEM SET db_re...
rman-06025归档日志被删除
最新发布
07-10
<think>我们正在处理RMAN-06025错误，该错误发生在尝试恢复归档日志时，但该日志已被删除。根据引用[3]的描述，错误信息为："RMAN-06025: no backup of archived log for thread 2 with sequence 427592 and starting SCN of 1298100864731 found to restore"。这意味着RMAN在恢复过程中找不到指定序列号的归档日志备份。 用户提到归档日志已经被删除，因此我们需要解决如何在没有归档日志的情况下继续恢复。 解决方案通常包括以下步骤： 1. **确认归档日志确实缺失**：首先，我们需要确认该归档日志是否确实不可用（例如，已经被删除且没有备份）。可以通过RMAN的`list archivelog`命令来检查。 2. **使用不完全恢复**：由于缺少归档日志，我们无法进行完全恢复。因此，可以考虑进行不完全恢复，将数据库恢复到缺失日志之前的时间点。 3. **跳过缺失的归档日志（不推荐）**：在某些情况下，如果缺失的日志不是关键事务（例如，非关键表的数据操作），我们可以尝试通过设置`_allow_resetlogs_corruption`隐含参数来强制打开数据库，但这会导致数据不一致，仅作为最后手段。 4. **从其他来源恢复归档日志**：如果存在其他备份（如磁盘上的归档日志副本、远程备库的归档日志等），可以尝试将这些日志复制到指定位置，然后通过RMAN的`catalog`命令将其添加到资料库中。 5. **使用备份控制文件**：如果控制文件也是旧的，可能需要恢复控制文件到缺失日志之前的状态。 然而，根据用户描述，归档日志已经被删除，且没有备份（否则RMAN应该能找到备份），因此我们重点考虑不完全恢复。 具体步骤： 步骤1：确定恢复终点 由于我们无法恢复指定的归档日志，因此需要确定一个恢复终点，即在该日志之前的一个时间点或SCN。我们可以使用以下命令： ``` RUN { SET UNTIL SCN <missing_log_start_scn - 1>; # 使用缺失日志的起始SCN减1，确保在缺失日志之前 RESTORE DATABASE; RECOVER DATABASE; } ``` 或者使用时间点： ``` RUN { SET UNTIL TIME "to_date('YYYY-MM-DD HH24:MI:SS', 'nls_date_language=american')"; RESTORE DATABASE; RECOVER DATABASE; } ``` 步骤2：以resetlogs方式打开数据库 不完全恢复后，需要使用`resetlogs`选项打开数据库： ``` ALTER DATABASE OPEN RESETLOGS; ``` 注意：使用`resetlogs`会重置日志序列号，因此之前的所有备份将不再可用，需要重新进行全备。 步骤3：重建备库（如果存在） 如果有备库，需要重新搭建，因为`resetlogs`会改变数据库的incarnation。 但是，如果用户需要恢复到缺失日志之后的时间点，那么这种方法就不适用了。在这种情况下，可能需要尝试从其他来源获取缺失的归档日志（例如，从备库、操作系统级别的备份等）。 另外，引用[4]中提到了一种情况：在DG环境中，主库无法删除归档日志，因为备库需要这些日志。但这里的问题是备库缺失了部分日志，导致主库无法删除。不过，我们当前的问题不是删除归档日志，而是恢复时缺少归档日志。因此，引用[4]的解决方案并不直接适用。 如果用户有多个归档日志备份，但RMAN没有找到，可能是因为备份记录在恢复目录中丢失。这时，我们可以尝试手动将备份的归档日志注册到RMAN资料库中： ``` CATALOG ARCHIVELOG '/path/to/archivelog/archive_log_file_name.arc'; ``` 但用户已经说明归档日志被删除，所以这一步骤可能不适用。 总结：主要解决方案是不完全恢复。 下面，我们按照要求生成相关问题。</think>### RMAN-06025 错误解决方案（归档日志被删除） 当遇到 RMAN-06025 错误（`no backup of archived log found to restore`）且归档日志已被物理删除时，可按以下步骤解决： --- #### **1. 确认日志状态** ```sql LIST ARCHIVELOG ALL; -- 列出所有归档日志 LIST BACKUP OF ARCHIVELOG ALL; -- 检查备份记录 ``` - 若日志在控制文件中存在记录但物理文件已删除，会显示 `AVAILABLE` 但实际不可用[^3]。 --- #### **2. 解决方案** **方法一：不完全恢复（推荐）** ```sql RUN { SET UNTIL SCN <缺失日志的起始SCN>; -- 使用报错中的 starting SCN（如1298100864731） RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS; -- 强制打开数据库 ``` **原理**：恢复到缺失日志**之前**的 SCN，跳过损坏/丢失的日志[^1][^2]。 **方法二：清理无效记录** ```sql CROSSCHECK ARCHIVELOG ALL; -- 验证日志状态 DELETE EXPIRED ARCHIVELOG ALL; -- 删除控制文件中的无效记录 ``` - 清理后重新执行恢复操作，RMAN 将跳过无法恢复的日志。 --- #### **3. 预防措施** - **备份策略**：定期备份归档日志并保留冗余副本 ```sql BACKUP ARCHIVELOG ALL DELETE INPUT; -- 备份后自动删除原日志 ``` - **日志保留**：设置保留策略避免误删 ```sql CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK; ``` - **监控脚本**：添加日志清理前的检查逻辑 ```bash #!/bin/bash rman target / <<EOF CROSSCHECK ARCHIVELOG ALL; EOF ``` --- #### **关键注意事项** 1. **`OPEN RESETLOGS` 风险**： - 会重置日志序列号，需立即全量备份 - 可能导致 Data Guard 备库失效，需重建[^4] 2. **数据一致性**： - 不完全恢复会丢失缺失日志之后的数据 - 需评估业务容忍度，优先通过备份恢复事务关键数据 3. **跨版本恢复**： - 若涉及跨版本恢复（如 11g→19c），先执行 `UPGRADE` 模式避免兼容性错误[^2] > **操作建议**：生产环境操作前，先克隆环境测试恢复流程。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值