您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
本篇内容主要讲解“怎么解决oracle丢失的是所有的redo日志组问题”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么解决oracle丢失的是所有的redo日志组问题”吧!
假设丢失的是所有的redo日志组，分下列几种情况分别处理：
1.Oracle没开归档，一致性关闭数据库
2.Oracle没开归档，非一致性关闭数据库
3.Oracle开归档，一致性关闭数据库
4.Oracle开归档，非一致性关闭数据库
一：Oracle没开归档，一致性关闭数据库
我做实验的过程中有一个诡异的情况，我先把redo文件从操作系统层面都删除了，但是数据库正常创建表，insert数据，我理解的是当你commit的时候，会触发lgwr进程从redo log buffer中涮新redo 到redo 文件中，但是redo文件已经被删除了，就会报错，但是他并没有报错：
[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# ll
total 13697796
-rw-r----- 1 oracle oinstall 144916480 Apr 5 22:30 control01.ctl
-rw-r----- 1 oracle oinstall 2147491840 Apr 5 22:26 liuwenhe.dbf
-rw-r----- 1 oracle oinstall 52429312 Apr 5 22:26 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Apr 5 22:29 redo03.log
-rw-r----- 1 oracle oinstall 4938801152 Apr 5 22:26 soe3.dbf
-rw-r----- 1 oracle oinstall 2469404672 Apr 5 22:26 soe.dbf
-rw-r----- 1 oracle oinstall 2705334272 Apr 5 22:26 sysaux01.dbf
-rw-r----- 1 oracle oinstall 786440192 Apr 5 22:26 system01.dbf
-rw-r----- 1 oracle oinstall 30416896 Oct 16 12:37 temp01.dbf
-rw-r----- 1 oracle oinstall 1073750016 Apr 5 22:26 temp.dbf
-rw-r----- 1 oracle oinstall 309338112 Apr 5 22:26 undotbs01.dbf
-rw-r----- 1 oracle oinstall 166469632 Apr 5 22:26 users01.dbf
删除redo 文件
[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# rm *.log
再次查看，发现确实已经没有了redo文件
[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# ll
total 13595388
-rw-r----- 1 oracle oinstall 144916480 Apr 5 22:50 control01.ctl
-rw-r----- 1 oracle oinstall 2147491840 Apr 5 22:50 liuwenhe.dbf
-rw-r----- 1 oracle oinstall 4938801152 Apr 5 22:50 soe3.dbf
-rw-r----- 1 oracle oinstall 2469404672 Apr 5 22:50 soe.dbf
-rw-r----- 1 oracle oinstall 2705334272 Apr 5 22:50 sysaux01.dbf
-rw-r----- 1 oracle oinstall 786440192 Apr 5 22:50 system01.dbf
-rw-r----- 1 oracle oinstall 30416896 Oct 16 12:37 temp01.dbf
-rw-r----- 1 oracle oinstall 1073750016 Apr 5 22:41 temp.dbf
-rw-r----- 1 oracle oinstall 309338112 Apr 5 22:50 undotbs01.dbf
-rw-r----- 1 oracle oinstall 166469632 Apr 5 22:50 users01.dbf
SQL> create table t(int int);
Table created.
SQL> insert into t values (100);
1 row created.
SQL> commit;
SQL>alter system switch logfile;
System altered.
SQL> alter system checkpoint;
System altered.
有点理解不了!!!!问了下老师，才知道原来是打开的文件句柄还在，重启之后就没有了!就会报错
(体外话：也就是说rm这个文件了，但是这个文件实际上还是存在的，先说一下他的工作原理吧，然后我在把试验分享给大家， 工作原理其实也不难，这个工具需要在ext3或者ext4 的文件系统上才可以实现，因为ext3文件系统是日志型文件系统，ext3文件系统储存信息的时候是由inode号和block块存储的。
神马? 不知道什么是inode号?和block块? 好吧，在说明白点，比如：一个分区比如一本书，那么block块就是书每页的内容，而inode号 就是书的目录，系统找文件的时候先找inode号 然后根据inode号去找硬盘上的block快信息，明白了吧!
在说一下删除的原理吧。 当硬盘上的一个文件删除，其实没有真正想象中的那样在硬盘上清除掉的，他是把inode号和block块的那个链子 断开，但是真正的数据还是在硬盘上的，有没有感觉在windos上删除是那么快，没考虑到这吧，当你在删除文件的地方重新复制了新文件，那时候才会把之前的文件覆盖掉，也就是说删除了没有关系，千万不要往那个位置放文件了)
因为数据库是一致性关闭的，也就是不需要实例恢复，也就不需要丢失的redo，所以可以直接删除重建，当然也可以recover database 来恢复丢失的redo,所以针对这种情况，有两种恢复方式：
方法一：直接clear相应的redo日志组!也就是删除重新建立!
SQL> shutdown immediate #一致性关闭
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 1275071648 bytes
Database Buffers 318767104 bytes
Redo Buffers 7319552 bytes
Database mounted.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 30641
Current log sequence 30642
清理删除从新建立或者直接clear所有的redo 日志组，包括当前状态的和active状态的redo 日志组!
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
SQL> alter database open ;
Database altered.
方法二：recover的方式恢复重做日志，我的实验过程中，有的时候这个方法会报错，如果报错那么就使用第一种方式恢复!
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 830930944 bytes
Fixed Size 2257800 bytes
Variable Size 536874104 bytes
Database Buffers 289406976 bytes
Redo Buffers 2392064 bytes
Database mounted.
SQL>
###恢复丢失的redo文件，但是需要open resetlogs之后才能自动创建上!
SQL> recover database until cancel;
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
二：Oracle没开归档，非一致性关闭数据库
[root@testdb59 /data/u01/app/oracle/oradata/stdb59]# rm -f *.log
SQL> shu abort ###非一致性关闭数据库
ORACLE instance shut down.
这个时候尝试使用前面的clear或者recover database都会报错，无法恢复，因为这个时候是需要做实例恢复的，那么什么时候需要实例恢复的判断依据，请参考另一篇文章(Oracle原理-----关于oracle实例恢复的前滚和回滚的理解)，报错如下：
首先尝试重建，当你尝试clear当前的日志组的时候，会报错提示是需要的!!!因为非一致性关闭确实需要使用丢失的active和current状态的redo来实例恢复!
首先启动数据库到mount状态
SQL> alter database clear logfile group 3;
alter database clear logfile group 3
*
ERROR at line 1:
ORA-01624: log 3 needed for crash recovery of instance stdb59 (thread 1)
ORA-00312: online log 3 thread 1:
'/data/u01/app/oracle/oradata/stdb59/redo03.log'
然后尝试recover database,结果肯定不可以，因为实例恢复需要的redo已经丢失!!
SQL> recover database until cancel;
ORA-00279: change 21959466 generated at 04/06/2019 21:15:45 needed for thread 1
ORA-00289: suggestion :
/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%
u_.arc
ORA-00280: change 21959466 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open RESETLOGS;
alter database open RESETLOGS
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'
那么针对这种情况，恢复的方式如下：
使用一个隐含参数_allow_resetlogs_corruption强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，到达open数据库的目的
SQL> create pfile='/home/oracle/pfile.ora' from spfile;
File created.
然后在/home/oracle/pfile.ora添加上
*._allow_resetlogs_corruption=true
SQL> startup mount pfile='/home/oracle/pfile.ora';
SQL> recover database until cancel; #恢复丢失的redo文件
ORA-00279: change 21959471 generated at 04/06/2019 22:34:01 needed for thread 1
ORA-00289: suggestion :
/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%
u_.arc
ORA-00280: change 21959471 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'
ORA-01112: media recovery not started
幸运的话就可以直接以resetlogs方式open数据库了!
SQL> alter database open RESETLOGS;
Database altered.
如果遇到下面的错误，那么你就得重建控制文件了：
SQL> alter database open RESETLOGS;
alter database open RESETLOGS
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [2662], [0], [21959484], [0],
[21959877], [4194545], [], [], [], [], [], []
Process ID: 13177
Session ID: 63 Serial number: 5
重建数据库控制文件
1)直接使用如下alter database backup controlfile这种会报错
SQL> alter database backup controlfile to trace as '/data/u01/control_rebuild.trc';
alter database backup controlfile to trace as '/data/u01/control_rebuild.trc'
*
ERROR at line 1:
ORA-16433: The database must be opened in read/write mode.
2)还可以使用如下特定的格式来重建，
查询数据库的redo 信息：
SQL> select GROUP#,MEMBER from v$logfile;
GROUP# MEMBER
3 /data/u01/app/oracle/oradata/stdb59/redo03.log
1 /data/u01/app/oracle/oradata/stdb59/redo01.log
查询数据库的datafile信息
SQL> select MEMBER from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/data/u01/app/oracle/oradata/stdb59/redo03.log
/data/u01/app/oracle/oradata/stdb59/redo01.log
/data/u01/app/oracle/oradata/stdb59/redo04.log
/data/u01/app/oracle/oradata/stdb59/redo05.log
/data/u01/app/oracle/oradata/stdb59/redo06.log
/data/u01/app/oracle/oradata/stdb59/redo07.log
查出数据库字符集：
SQL> select userenv('language') nls_lang from dual;
NLS_LANG
----------------------------------------------------
AMERICAN_AMERICA.AL32UTF8
然后编辑出创建控制文件的脚本：注意这里的的testdb57为数据库(db_name),如果是adg转换成的主库，不要写db_unique_name
CREATE CONTROLFILE REUSE DATABASE 'testdb57' NORESETLOGS ARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 226
LOGFILE
GROUP 3 '/data/u01/app/oracle/oradata/stdb59/redo03.log' SIZE 50M,
GROUP 1 '/data/u01/app/oracle/oradata/stdb59/redo01.log' SIZE 50M
DATAFILE
'/data/u01/app/oracle/oradata/stdb59/system01.dbf',
'/data/u01/app/oracle/oradata/stdb59/sysaux01.dbf',
'/data/u01/app/oracle/oradata/stdb59/undotbs01.dbf',
'/data/u01/app/oracle/oradata/stdb59/users01.dbf',
'/data/u01/app/oracle/oradata/stdb59/liuwenhe.dbf',
'/data/u01/app/oracle/oradata/stdb59/soe.dbf',
'/data/u01/app/oracle/oradata/stdb59/soe3.dbf'
CHARACTER SET AL32UTF8;
然后直接将数据库启动到nomount状态，执行创建脚本即可
SQL> startup nomount pfile='/home/oracle/pfile.ora';
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 1275071648 bytes
Database Buffers 318767104 bytes
Redo Buffers 7319552 bytes
CREATE CONTROLFILE REUSE DATABASE 'testdb57' NORESETLOGS ARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 226
LOGFILE
GROUP 3 '/data/u01/app/oracle/oradata/stdb59/redo03.log' SIZE 50M,
GROUP 1 '/data/u01/app/oracle/oradata/stdb59/redo01.log' SIZE 50M
DATAFILE
'/data/u01/app/oracle/oradata/stdb59/system01.dbf',
'/data/u01/app/oracle/oradata/stdb59/sysaux01.dbf',
'/data/u01/app/oracle/oradata/stdb59/undotbs01.dbf',
'/data/u01/app/oracle/oradata/stdb59/users01.dbf',
'/data/u01/app/oracle/oradata/stdb59/liuwenhe.dbf',
'/data/u01/app/oracle/oradata/stdb59/soe.dbf',
'/data/u01/app/oracle/oradata/stdb59/soe3.dbf'
CHARACTER SET AL32UTF8;
Control file created.
然后使用oradebug推进内存中scn号,以便于执行后面的recover来恢复丢失的redo文件，因为recover的过程会读取内存中scn。注意 alter session set events '10015 trace name adjust_scn level 10';这种方式在11.2.0.4已经失效了
(题外话：我们先聊聊Oracle的SCN。在数据库内部，SCN是一个单向递增的数字编号，控制文件、数据文件、在线Redo日志、归档日志和备份集合中，都包括这个数字编号。在内部文件中，SCN是通过Base和Wrap两个部分进行保存。Base是SCN编号的基础位，是通过32位二进制位进行保存。一旦超过这32位长度，系统会自动在Wrap进位。也就是说，Wrap表示的超过4G个数的进位次数)
SQL> oradebug poke 0x06001AE70 4 0x001B7740
oradebug 推进scn号，poke命令中，第一位参数是对应写入的内存位数，第二位参数是写入长度，第三位参数是写入取值。默认写入取值是10进制，我们在这里指定写入16进制(0x开头)，每一个取值段，用8个16进制对应，对应到数字位数是4位
首先查出数据库的控制文件中的scn号
SQL> select file#, checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 21959486
2 21959486
3 21959486
4 21959486
5 21959486
6 21959486
7 21959486
7 rows selected.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 014F14A2 00000001 00000000 00000000 000000EB 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> oradebug poke 0x06001AE70 4 21959486
BEFORE: [06001AE70, 06001AE74) = 00000000
AFTER: [06001AE70, 06001AE74) = 014F133E
(或者可以把21959486转换成16进制，然后再修改
SQL> select to_char(21959486, 'XXXXXXXXXXX') from dual;
TO_CHAR(2195
------------
14F133E
SQL> oradebug poke 0x06001AE70 4 0x14F133E
BEFORE: [06001AE70, 06001AE74) = 00000000
AFTER: [06001AE70, 06001AE74) = 014F133E)
再次查看确实已经变成了014F133E(对应10进制是21959486)
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 014F133E 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
然后执行recover进行不完全恢复：
SQL> recover database until cancel;
ORA-00279: change 21959486 generated at 04/06/2019 23:52:28 needed for thread 1
ORA-00289: suggestion :
/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_07/o1_mf_1_2_%
u_.arc
ORA-00280: change 21959486 for thread 1 is in sequence #2
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.
至此恢复成功!
三：oracle开归档，一致性关闭
这种情况是同情况1，不需要做实例恢复，所以可以直接删除从新或者recover所有的redo组即可，
方法一：直接clear相应的redo日志组!也就是删除重新建立!
SQL> shutdown immediate #一致性关闭
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 1275071648 bytes
Database Buffers 318767104 bytes
Redo Buffers 7319552 bytes
Database mounted.
清理删除从新建立或者直接clear所有的redo 日志组，包括当前状态的和active状态的redo 日志组!
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
SQL> alter database open ;
Database altered.
方法二：recover的方式恢复重做日志，我的实验过程中，有的时候这个方法会报错，如果报错那么就使用第一种方式恢复!
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 830930944 bytes
Fixed Size 2257800 bytes
Variable Size 536874104 bytes
Database Buffers 289406976 bytes
Redo Buffers 2392064 bytes
Database mounted.
SQL>
###恢复丢失的redo文件，但是需要open resetlogs之后才能自动创建上!
SQL> recover database until cancel;
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
四：开归档，非一致性关闭;
这种情况，只能借助归档日志做不完全恢复!
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1 1 39 52428800 512 1 YES
INACTIVE 4318162327 20-APR-19 4318209770 20-APR-19
3 1 40 52428800 512 1 NO
CURRENT 4318209770 20-APR-19 2.8147E+14
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 39
Next log sequence to archive 40
Current log sequence 40
删除redo log文件
[oracle@testdb59 stdb59]$ rm -f *.log
然后非一致性关闭
SQL> shu abort
ORACLE instance shut down.
解决过程：
SQL> startup mount
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 1275071648 bytes
Database Buffers 318767104 bytes
Redo Buffers 7319552 bytes
Database mounted.
###恢复丢失的redo文件，但是需要open resetlogs之后才能自动创建上!
SQL> recover database until cancel;
Media recovery complete.
尝试resetlog方式打开，如果报错如下，那么还得借助隐含参数_allow_resetlogs_corruption;
SQL> alter database open RESETLOGS;
alter database open RESETLOGS
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data/u01/app/oracle/oradata/stdb59/system01.dbf'
使用一个隐含参数_allow_resetlogs_corruption强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，到达open数据库的目的
SQL> create pfile='/home/oracle/pfile.ora' from spfile;
File created.
然后在/home/oracle/pfile.ora添加上
*._allow_resetlogs_corruption=true
SQL> startup mount pfile='/home/oracle/pfile.ora';
SQL> alter database open RESETLOGS;
Database altered.
然后一致性关闭数据库，去掉隐含参数_allow_resetlogs_corruption，重启数据库!
到此，相信大家对“怎么解决oracle丢失的是所有的redo日志组问题”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。