redo日志丢失情况种种（帖子不错，先转过来，以后需要时可参考一下）

最新推荐文章于 2024-07-12 08:45:00 发布
最新推荐文章于 2024-07-12 08:45:00 发布
阅读量2.8k 收藏 2
点赞数
分类专栏： ORACLE 文章标签： database 数据库 sql system oracle table

平常心试验第一课：redo日志丢失情况种种

--试验环境 oracle10.2.0.4
--平常心 redo系列实验1（--现实中的可能：断电，redo日志组全部丢失。）
--步骤1：先创建一个表
create table newback03 as select * from v$log;
--步骤2：使得创建表的变化没有写入到数据文件中，只写在当前日志redo01.log文件中，并且redo01.log没有归档。模拟断电
shutdown abort
--步骤3：将redo01.log,redo02.log,redo02.log全部重命名(模拟redo全部丢失)
--步骤4：将数据库启动到mount状态，这个时候数据库是无法open的
startup mount
--步骤5：执行数据库恢复，数据文件处于不一致的状态，又无法从归档日志中恢复，那么建表语句就丢失了。
--数据库丢失了数据。你就哭吧。
recover database until cancel;

--试验模拟的结果
SQL> create table newback01 as select * from v$log;
表已创建。
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area  167772160 bytes
Fixed Size                  1295632 bytes
Variable Size             104860400 bytes
Database Buffers           58720256 bytes
Redo Buffers                2895872 bytes
数据库装载完毕。
SQL> recover database until cancel;
ORA-00279: 更改 1152128 (在 11/02/2009 17:20:16 生成) 对于线程 1 是必需的
ORA-00289: 建议:
C:/ORACLE/PRODUCT/10.2.0/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2009_11_02/O1_MF_1_2_%U_.ARC
ORA-00280: 更改 1152128 (用于线程 1) 在序列 #2 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: 无法打开归档日志
'C:/ORACLE/PRODUCT/10.2.0/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2009_11_02/O1_MF_1
_2_%U_.ARC'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSTEM01.DBF'
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSTEM01.DBF'

教育我们：redo文件组需要创建多个组，建议至少3个，每个组至少2个文件，最好放在不同的硬盘上。
如果不幸发生了断电，并且所有的redo丢失。这是最糟糕的情况。
一般不会发生，如果发生了，你家祖坟就冒青烟了，你可以去买88倍投的彩票了。



--平常心 redo系列的实验2（--现实中的可能，数据库正常关闭，单位不爽你很久的某个人，趁你不注意，把你redo文件全部删除了）
--步骤1：先创建一个表
create table newback02 as select * from v$log;
--步骤2：使得创建表的变化写入到数据文件中。
shutdown immediate
--步骤3：将redo01.log,redo02.log,redo02.log全部重命名(模拟redo全部丢失)
--步骤4：将数据库启动到mount状态，这个时候数据库是无法open的
startup mount
--步骤5：执行数据库恢复，恢复正常。
recover database until cancel;
--步骤6：执行数据库打开，没有丢失任何数据
alter database open resetlogs;
--步骤7：立即用rman执行全库备份（备份的方法我就不在这里啰嗦了，但是我要强调resetlogs之后全库备份的重要性
--10g之前的版本中oracle是不能使用resetlogs之前的备份的。10g版本是可以穿越resetlogs进行恢复的，这个还得研究一下）

--试验模拟的结果
SQL> create table newback02 as select * from v$log;
表已创建。
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area  167772160 bytes
Fixed Size                  1295632 bytes
Variable Size             104860400 bytes
Database Buffers           58720256 bytes
Redo Buffers                2895872 bytes
数据库装载完毕。
SQL> recover database until cancel;
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。
--结果：正常恢复数据库。数据没有丢失，坏人没有得逞。但是执行了resetlogs。这给备份恢复管理带来了很多麻烦，但是只能这样了。





--平常心 redo系列实验3（现实中的可能：你有3组文件 redo01，redo02，redo03。有一次数据库正常关闭后。丢失了redo02，redo03.当前组是redo01）
SQL> select group#,archived,status from v$log;
     GROUP# ARC STATUS
---------- --- ----------------
     1   NO    CURRENT
     2   YES   INACTIVE
     3   YES   INACTIVE
SQL> create table newback05 as select * from v$log;
表已创建。
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area  167772160 bytes
Fixed Size                  1295632 bytes
Variable Size             104860400 bytes
Database Buffers           58720256 bytes
Redo Buffers                2895872 bytes
数据库装载完毕。
SQL> alter database clear logfile group 2;
数据库已更改。
SQL> alter database clear logfile group 3;
数据库已更改。
SQL> alter database open;

--结果。一切正常，数据没有丢失，不用resetlogs。




--平常心 redo系列实验4（数据库正常关闭，当前日志redo01损坏）
select group#,archived,status from v$log;
1        1        NO        CURRENT
2        2        YES        ACTIVE
3        3        YES        ACTIVE
--第一步
shutdown immediate; 完成之后日志组2、3状态就是INACTIVE了。如果shutdown abort 就还是ACTIVE。断电很可怕啊
--第二步
startup mount;
--第三步 修改redo01的内容，用记事本打开，删掉部分乱码
--第四步：
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
第 1 行出现错误:
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
ORA-00312: 联机日志 1 线程 1:
'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG'
ORA-27046: 文件大小不是逻辑块大小的倍数
OSD-04012: 文件大小不匹配 (OS 52267343)
--注意：网络上有说用 alter database clear unarchived logfile group 1 恢复成功的，但是前提是有redo的备份。
SQL> recover database until cancel;
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。



--平常心redo实验5（多个日志组，每个日志多个成员的好处）
--第一步：我们先看一下目前的状态
select group#,archived,status from v$log;
GROUP#        ARCHIVED        STATUS
1        1        YES        INACTIVE
2        3        NO        CURRENT
3        2        YES        INACTIVE
select * from v$logfile
GROUP#        STATUS        TYPE        MEMBER        IS_RECOVERY_DEST_FILE
3                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG        NO
2                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG        NO
1                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG        NO
--第二步：
--每个组增加一个成员（注意：如果open状态增加，当前组需切换后才能增加）
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo01b.log' to group 1;
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo02b.log' to group 2;
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo03b.log' to group 3;

--第三步：创建表
create table newback10 as select * from v$log;
--第四步：切换日志
alter system switch logfile;
alter system switch logfile;
alter system switch logfile;
--第五步：再看一下select * from v$logfile
GROUP#        STATUS        TYPE        MEMBER        IS_RECOVERY_DEST_FILE
3                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG        NO
2                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG        NO
1                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG        NO
1                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG        NO
2                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02B.LOG        NO
3                            ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03B.LOG        NO
--第六步：shutdown abort 停电了
--第七步：每组坏掉一个日志B
--第八步：startup mount;
--第九步：alter database open;
--第十步：看一下数据库表desc newback10 正常
--第十一步：再看一下select * from v$logfile
GROUP#        STATUS        TYPE        MEMBER        IS_RECOVERY_DEST_FILE
        3            STALE          ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG        NO
        2                          ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG        NO
        1                          ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG        NO
        1            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG        NO
        2            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02B.LOG        NO
        3            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03B.LOG        NO
--第十二步：切换一下日志
alter system switch logfile;
alter system switch logfile;
alter system switch logfile;
--第十三步：再看一下select * from v$logfile
GROUP#        STATUS        TYPE        MEMBER        IS_RECOVERY_DEST_FILE
        3                    ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG        NO
        2                          ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG        NO
        1                          ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG        NO
        1            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG        NO
        2            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02B.LOG        NO
        3            INVALID        ONLINE        C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03B.LOG        NO
--第十四步：看来一切正常，我们再把丢失的文件加上去
ALTER DATABASE ADD LOGFILE 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG' size 50M;
ORA-01577无法添加日志文件，已存在。我们先要将无效的日志组成员删除，注意当前日志组需要切换后才能删除。
ALTER DATABASE DROP LOGFILE MEMBER 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01B.LOG';
ALTER DATABASE DROP LOGFILE MEMBER 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02B.LOG';
ALTER DATABASE DROP LOGFILE MEMBER 'C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03B.LOG';
--最后。删除完成。再加上吧
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo01b.log' to group 1;
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo02b.log' to group 2;
alter database add logfile member 'C:/oracle/product/10.2.0/oradata/orcl/redo03b.log' to group 3;

--结果，oracle虽然只要求2个日志组，每组一个成员就可以工作，但是我们推荐至少3个日志组，每个组至少2个成员
--即使你丢失了每个组个一个成员，数据库也是可以做到不会丢失任何数据。



总结：情况一：
数据库正常关闭的情况下，所有的变化都已经写入到数据文件中了，数据不会有任何丢失，
即使所有redo都丢失了，也没有关系。可以使用recover database until cancel来恢复数据库。
如果丢失除current之外的已经归档了的redo，那么不用去recover也可以恢复。clear一下也就行了。
如果丢失的redo如果没有规档，也是要执行recover database unti cancel 来恢复。
情况二：
数据库不正常关闭的情况下，如果redo文件全部损坏，那肯定是要丢失数据的。
较好的情况是current没有坏，其它redo状态时INACTIVE并且已经归档了，但是丢失了。
最坏的情况，数据库不正常关闭，redo文件全部损坏，redo的状态是active和current，无法删除和创建redo文件
这种情况下只能做imcomplete恢复，如果没有备份，你的数据库可能就无法恢复了。
lianruidong
关注
专栏目录
全网最通透：MySQL 的 redo log 保证数据不丢的原理
m0_71777195的博客
08-26 880
存储引擎是 MySQL 中直接与磁盘交互部分。页是存储引擎读写数据的最小单位，一个页里可以有一条或多条表记录。MySQL 中的存储引擎有很多种，比如 InnoDB、MyISAM、Memory 等。其中最常用的是 InnoDB。而 InnoDB 是 MySQL 中唯一能够完整支持事务特性的存储引擎，也是一个高性能的存储引擎。本文要讲的「两段式提交」就发生在 InnoDB 中。...
oracle日志重建,Oracle在线 redo log文件丢失后的恢复
weixin_39944638的博客
04-03 403
今天一个开发库启动不了了，发过来报错一看是日志文件损坏了(见下图)，接着说了一下前因后果。说是年前服务器掉电了，然后就再没有启动起来过。今天有人用才想到要处理。 先说一下大体的思路，如果损坏的redo log是INACTIVE状态的，也就是实例崩溃恢复用不到的redo log，那处理起来比较容易，直接alter database clear logfile group #;或alter datab...
oracle丢失的是所有的redo日志组
cke63021的博客
04-20 273
假设丢失的是所有的redo日志组，分下列几种情况分别处理： 1.Oracle没开归档，一致性关闭数据库 2.Oracle没开归档，非一致性关闭数据库 3.Oracle开归档，一致性关闭数据库 ...
Redo丢失的4种情况及处理方法
最新发布
weixin_tank88921的博客
07-12 679
FUZZY等于NO，且数据库的终止SCN等于启动SCN等于数据文件SCN，那么可以认为数据库是正常关闭，且在打开数据库之前不需要执行实例恢复或Crash恢复。FUZYY表示模糊性，意思是，该数据文件处于模糊状态，在最近一次CHECKPOINT后，该文件上的数据可能被修改过了，但没来得及更新到该文件上（或者该文件不知道），需要读取日志信息来判断。非正常关闭的当前日志丢失，可能导致数据库启动后的混乱，并可能造成少量数据的丢失。其他情况不会导致数据的丢失。非正常关闭数据库实例，FUZZY字段的值是YES。
redo log 丢失或者损坏-ORA-01194: 文件 1 需要更多的恢复来保持一致性
Lixora's DB Home
11-23 1110
ORA-00312: 联机日志 2 线程 1: 'C:\ORACLE19C\APP\ZMI\ORADATA\ORCL\REDO02.LOG'ORA-01110: 数据文件 1: 'C:\ORACLE19C\APP\ZMI\ORADATA\ORCL\SYSTEM01.DBF'ORA-01110: 数据文件 1: 'C:\ORACLE19C\APP\ZMI\ORADATA\ORCL\SYSTEM01.DBF'2、ORA-01194: 文件 1 需要更多的恢复来保持一致性。ORA-27041: 无法打开文件。
Oracle特殊恢复原理与实战_07 归档模式下缺失Redo Log后的恢复
weixin_42492728的博客
03-25 1083
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/orcl/redo02.log' # 提示打开 log group 2 失败。OP:11.19-update修改的值 TYP:2-类型2是普通文件 CLS:1-数据类型 AFN:9-绝对文件号 DBA:0x02400e87-数据文件地址 OBJ:94895-对象编号。OP:5.1-update修改前的值 AFN:3-绝对文件号(这个文件对应的是undo file)
redolog能否保证MySQL数据库异常重启之后数据不丢失？
学亮编程手记
12-05 455
当数据库发生异常重启时，MySQL会使用Redo Log来进行崩溃恢复操作，将未提交的事务回滚，并将已提交的事务重新应用到数据库中，从而将数据恢复到一致的状态。综上所述，Redo Log在MySQL中是确保事务的持久性和崩溃恢复的重要组件，它能够在一定程度上帮助保证MySQL数据库在异常重启之后数据不丢失。数据库备份是将数据库的快照保存到另一个位置，以便在数据丢失时进行恢复。它记录了数据库中发生的修改操作，在数据库异常重启时能够通过Redo Log来恢复未提交的事务或回滚已提交的事务，以保证数据的一致性。
oracle丢失redo文件,Oracle在线 redo log文件丢失后的恢复
weixin_42511714的博客
04-04 471
今天一个开发库启动不了了，发过来报错一看是日志文件损坏了(见下图)，接着说了一下前因后果。说是年前服务器掉电了，然后就再没有启动起来过。今天有人用才想到要处理。先说一下大体的思路，如果损坏的redo log是INACTIVE状态的，也就是实例崩溃恢复用不到的redo log，那处理起来比较容易，直接alter database clear logfile group #;或alter databa...
oracle表恢复 日志,Oracle数据库在线重做日志被删除的几种恢复方法
weixin_29467909的博客
04-07 646
Oracle数据库的在线重做日志中包含了数据库中所有数据的操作记录，我们可以利用重做日志做很多的操作，例如日志挖掘。有时候，因为种种原因，我们的在线日志被人误删除或者意外损坏掉，我们应该如何进行恢复呢，其实很简单，看下面内容：我们通过删除在线日志模拟日志被误删除的情况：[oracle@test orcl]$ rm redo*[oracle@test orcl]$ ls -l redo*ls: 无法...
数据库基础知识——事务与恢复系统
qq_31310053的博客
02-17 919
数据库基础知识——事务与恢复系统事务事务的ACID特性事务并发执行时会产生的问题数据库中的锁机制事务的隔离级别恢复系统故障分类日志系统故障恢复策略基于检查点的日志恢复系统 事务 什么是事务？ 是由多个操作封装起来的一个执行单元，这个执行单元内的操作要么都做，要么都不做 事务的ACID特性 原子性（Atom） 事务内的操作要么都做，要么都不做。 一致性（Consistency） 事务执行后应保...
redo丢失的各种情况处理
Du.的博客
11-11 1603
redo丢失的各种情况处理
详细分析MySQL事务日志(redo log和undo log)
weixin_33831673的博客
05-08 587
innodb事务日志包括redo log和undo log。redo log是重做日志，提供前滚操作，undo log是回滚日志，提供回滚操作。 undo log不是redo log的逆向过程，其实它们都算是用来恢复的日志： 1.redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置...
redo日志保证事务提交后数据绝对不会丢的机制
yyyy11119的博客
11-10 1048
Buffer Pool整体机制在MySQL进行更新操作的时候会先更新Buffer Pool中的缓存页之后，必须写一条redo log,这样才能记录下对数据库的修改，这样的话也可以保证我们事务提交之后，如果Buffer Pool中脏页还没有刷到磁盘上去时，MySQL发生宕机，那么MySQL重启后，就可以把redo log重做一遍，恢复出当时事务事务更新的缓存页，然后再把缓存页刷到磁盘，这样的话red...
oracle redo01. log,redo01.log恢复问题
weixin_39725650的博客
04-04 697
背景： 在正常oracle11g正常open状态，我操作系统mv 了redo01.log然后rman不知道该怎么恢复。可是通过下面的脚本居然重建了redo01.log我不知道哪一步能重建的.看哪个日志可以知道呢？ps：操作过程如下：SQL> select member from v$logfile;MEMBER-----------------------------------------...
开启Oracle的RedoLog配置
sunny05296的博客
07-20 2893
Oracle Redo Log配置： 大致修改步骤： 1.安装logminer 2.开启日志的归档模式 3.开启补充日志(primary key,unique,foreign key,all) 4.日志优化（调整在线日志文件大小和个数） 5.创建redolog同步账号 step1：安装logminer --安装logminer SQL&gt; conn / as sysdba SQL&gt; ...
Oracle重做日志丢失的故障处理
abc123098098的博客
03-28 310
Oracle重做日志 Oracle的重做日志文件(Online redo logfile)循环记录了数据库所有的事务。它的大小、个数和存储位置对数据库性能和恢复有重要影响。它一般由大小相同的几组文件构成。我们可以查看数据库视图v$logfile知道redo logfile的个数和存储位置。对每一个Oracle数据库都要求至少具有两个联机重做日志。 每一次新的事务提交时，Oracle将...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值