怎么解决oracle丢失的是所有的redo日志组问题

本篇内容主要讲解“怎么解决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]# lltotal 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]# lltotal 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.dbfSQL> 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 mountORACLE instance started.Total System Global Area 1603411968 bytesFixed Size 2253664 bytesVariable Size 1275071648 bytesDatabase Buffers 318767104 bytesRedo Buffers 7319552 bytesDatabase mounted.SQL> archive log list;Database log mode No Archive ModeAutomatic archival DisabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 30641Current 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 immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area 830930944 bytesFixed Size 2257800 bytesVariable Size 536874104 bytesDatabase Buffers 289406976 bytesRedo Buffers 2392064 bytesDatabase 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 *.logSQL> 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 1ORA-00289: suggestion :/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%u_.arcORA-00280: change 21959466 for thread 1 is in sequence #2Specify log: {=suggested | filename | AUTO | CANCEL}CANCELORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01194: file 1 needs more recovery to be consistentORA-01110: data file 1: ‘/data/u01/app/oracle/oradata/stdb59/system01.dbf’ORA-01112: media recovery not startedSQL> alter database open RESETLOGS;alter database open RESETLOGSERROR at line 1:ORA-01194: file 1 needs more recovery to be consistentORA-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=trueSQL> 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 1ORA-00289: suggestion :/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_06/o1_mf_1_2_%u_.arcORA-00280: change 21959471 for thread 1 is in sequence #2Specify log: {=suggested | filename | AUTO | CANCEL}CANCELORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01194: file 1 needs more recovery to be consistentORA-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 forcedORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00600: internal error code, arguments: [2662], [0], [21959484], [0],[21959877], [4194545], [], [], [], [], [], []Process ID: 13177Session 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# MEMBER3 /data/u01/app/oracle/oradata/stdb59/redo03.log1 /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_nameCREATE CONTROLFILE REUSE DATABASE ‘testdb57’ NORESETLOGS ARCHIVELOGMAXLOGFILES 50MAXLOGMEMBERS 5MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 226LOGFILEGROUP 3 ‘/data/u01/app/oracle/oradata/stdb59/redo03.log’ SIZE 50M,GROUP 1 ‘/data/u01/app/oracle/oradata/stdb59/redo01.log’ SIZE 50MDATAFILE’/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 bytesFixed Size 2253664 bytesVariable Size 1275071648 bytesDatabase Buffers 318767104 bytesRedo Buffers 7319552 bytesCREATE CONTROLFILE REUSE DATABASE ‘testdb57’ NORESETLOGS ARCHIVELOGMAXLOGFILES 50MAXLOGMEMBERS 5MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 226LOGFILEGROUP 3 ‘/data/u01/app/oracle/oradata/stdb59/redo03.log’ SIZE 50M,GROUP 1 ‘/data/u01/app/oracle/oradata/stdb59/redo01.log’ SIZE 50MDATAFILE’/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 0x001B7740oradebug 推进scn号，poke命令中，第一位参数是对应写入的内存位数，第二位参数是写入长度，第三位参数是写入取值。默认写入取值是10进制，我们在这里指定写入16进制(0x开头)，每一个取值段，用8个16进制对应，对应到数字位数是4位首先查出数据库的控制文件中的scn号SQL> select file#, checkpoint_change# from v$datafile;FILE# CHECKPOINT_CHANGE#———- ——————1 219594862 219594863 219594864 219594865 219594866 219594867 219594867 rows selected.SQL> oradebug setmypidStatement processed.SQL> oradebug DUMPvar SGA kcsgscn_kcslf kcsgscn_ [06001AE70, 06001AEA0) = 014F14A2 00000001 00000000 00000000 000000EB 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000SQL> oradebug poke 0x06001AE70 4 21959486BEFORE: [06001AE70, 06001AE74) = 00000000AFTER: [06001AE70, 06001AE74) = 014F133E(或者可以把21959486转换成16进制，然后再修改SQL> select to_char(21959486, ‘XXXXXXXXXXX’) from dual;TO_CHAR(2195————14F133ESQL> oradebug poke 0x06001AE70 4 0x14F133EBEFORE: [06001AE70, 06001AE74) = 00000000AFTER: [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 1ORA-00289: suggestion :/data/u01/app/oracle/fast_recovery_area/STDB59/archivelog/2019_04_07/o1_mf_1_2_%u_.arcORA-00280: change 21959486 for thread 1 is in sequence #2Specify log: {=suggested | filename | AUTO | CANCEL}CANCELORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA免费主机域名-01194: file 1 needs more recovery to be consistentORA-01110: data file 1: ‘/data/u01/app/oracle/oradata/stdb59/system01.dbf’ORA-01112: media recovery not startedSQL> 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 mountORACLE instance started.Total System Global Area 1603411968 bytesFixed Size 2253664 bytesVariable Size 1275071648 bytesDatabase Buffers 318767104 bytesRedo Buffers 7319552 bytesDatabase 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 immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area 830930944 bytesFixed Size 2257800 bytesVariable Size 536874104 bytesDatabase Buffers 289406976 bytesRedo Buffers 2392064 bytesDatabase 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 YESINACTIVE 4318162327 20-APR-19 4318209770 20-APR-193 1 40 52428800 512 1 NOCURRENT 4318209770 20-APR-19 2.8147E+14SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 39Next log sequence to archive 40Current log sequence 40删除redo log文件[oracle@testdb59 stdb59]$ rm -f *.log然后非一致性关闭SQL> shu abortORACLE instance shut down.解决过程：SQL> startup mountORACLE instance started.Total System Global Area 1603411968 bytesFixed Size 2253664 bytesVariable Size 1275071648 bytesDatabase Buffers 318767104 bytesRedo Buffers 7319552 bytesDatabase 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 consistentORA-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=trueSQL> startup mount pfile=’/home/oracle/pfile.ora’;SQL> alter database open RESETLOGS;Database altered.然后一致性关闭数据库，去掉隐含参数_allow_resetlogs_corruption，重启数据库!到此，相信大家对“怎么解决oracle丢失的是所有的redo日志组问题”有了更深的了解，不妨来实际操作一番吧！这里是云技术网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！

相关推荐: 怎么理解主库的DUMP线程

本篇内容主要讲解“怎么理解主库的D免费主机域名UMP线程”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么理解主库的DUMP线程”吧!1、多次select 交互，从库需要保存主库的信息2、注册从库信息3、读取从库发…