redo文件破坏使用隐含参数恢复数据库

数据库在没有归档的情况下active状态日志损坏SQL> select * from v$Log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM---------- ---------- ---------- -------------------- --- ---------------- ------------- --------- 1 1 2 52428800 1 NO ACTIVE 462055 07-SEP-12 2 1 3 52428800 1 NO CURRENT 462062 07-SEP-12 3 1 1 52428800 1 NO ACTIVE 461887 07-SEP-12 SQL> select * from v$logfile; GROUP# STATUS TYPE MEMBER IS_---------- ------- ----------------------------------------------- --- 3 ONLINE /u01/tiger/oradata/orcl/redo03.log NO 2 ONLINE /u01/tiger/oradata/orcl/redo02.log NO 1 ONLINE /u01/tiger/oradata/orcl/redo01.log NO SQL> ！cp /etc/passwd/u01/tiger/oradata/orcl/redo01.log SQL> shut abortOracle instance shut down.SQL> startupORACLE instance started. Total System Global Area 314572800 bytesFixed Size 1219136 bytesVariable Size 109053376 bytesDatabase Buffers 197132288 bytesRedo Buffers 7168000 bytesDatabase mounted.ORA-00313: open failed for members of log group 1 of thread 1ORA-00312: online log 1 thread 1:"/u01/tiger/oradata/orcl/redo01.log"ORA-27046: file size is not a multiple oflogical block sizeAdditional information: 1------启动的时候发现日志组1出现了问题SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM---------- ---------- ---------- -------------------- --- ---------------- ------------- --------- 1 1 2 52428800 1 NO ACTIVE 462055 07-SEP-12 3 1 1 52428800 1 NO ACTIVE 461887 07-SEP-12 2 1 3 52428800 1 NO CURRENT 462062 07-SEP-12----查看得出日志组1是active状态SQL> archive log listDatabase log mode No Archive ModeAutomatic archival DisabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 1Current log sequence 3------再看数据库的模式：得出是非归档状态SQL> recover database;ORA-00283: recovery session canceled due toerrorsORA-00313: open failed for members of loggroup 1 of thread 1ORA-00312: online log 1 thread 1:"/u01/tiger/oradata/orcl/redo01.log"ORA-27046: file size is not a multiple oflogical block sizeAdditional information: 1 SQL> recover database until cancel;ORA-00279: change 462055 generated at09/07/2012 14:03:23 needed for thread 1ORA-00289: suggestion :/u01/tiger/flash_recovery_area/ORCL/archivelog/2012_09_07/o1_mf_1_2_%u_.arcORA-00280: change 462055 for thread 1 is insequence #2 Specify log: {<RET>=suggested |filename | AUTO | CANCEL} ORA-00308: cannot open archived log "/u01/tiger/flash_recovery_area/ORCL/archivelog/2012_09_07/o1_mf_1_2_%u_.arc"ORA-27037: unable to obtain file statusLinux Error: 2: No such file or directoryAdditional information: 3ORA-01547: warning: RECOVER succeeded butOPEN RESETLOGS would get error belowORA-01194: file 1 needs more recovery to beconsistentORA-01110: data file 1:"/u01/tiger/oradata/orcl/system01.dbf"------上面恢复的时候看到数据库不是归档但是在恢复的时候他们要找归档日志这时候我们不恢复了直接启动数据库（借助隐含参数）设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，Open打开Oracle的隐含参数只应该在测试环境或者在Oracle Support的支持下使用SQL> alter system set"_allow_resetlogs_corruption"=true scope=spfile;System altered. 隐含参数：redo块损坏时第一，如果损坏的是非当前redo文件并且已经归档我们可以使用alter database clear logfile group 1清空该日志文件第二，如果损坏的是非当前redo文件并且该文件组没有归档此时使用alter database clear unarchived logfilegroup 1强行清空日志第三，归档模式下当前日志的损坏有两种情况：1、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏就可以直接用alter database clear unarchived logfile group n来重建。2、是日志组中有活动的事务，数据库需要介质恢复，日志组需要用来同步，有两种补救办法A:最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份B:通过强制性恢复，但是可能导致数据库不一致。SQL> shutdown immediateORA-01109: database not open Database dismounted.ORACLE instance shut down.SQL> startupORACLE instance started. Total System Global Area 314572800 bytesFixed Size 1219136 bytesVariable Size 109053376 bytesDatabase Buffers 197132288 bytesRedo Buffers 7168000 bytesDatabase mounted.ORA-01589: must use RESETLOGS orNORESETLOGS option for database open SQL> alter database open resetlogs; Database altered.没有备份的current状态的redo日志损坏ACTIVE日志损坏（有归档）相关资讯 redo

大量redo生成的问题原因及改进（09/06/2015 21:44:21）
Oracle 10g Standby Database 实时（12/22/2014 18:34:35）
普通表与临时表DML操作会产生REDO/ （09/17/2013 20:29:12）

online redo日志文件损坏恢复（01/11/2015 08:36:34）
Redo丢失的4种情况及处理方法（11/26/2014 11:12:28）
Oracle redo 日志调整（06/07/2013 16:13:00）

本文评论查看全部评论（0）