ORA-00399: corrupt change description in redo log : a workaround

Fix : ORA-00399: corrupt change description in redo log

In one of my test instance I found below issues and fixed with given workaround. You can try this.

SQL> startup;
ORACLE instance started.
.........
Database mounted.
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 113746 change 123790201307 time 08/07/2015
10:23:06
ORA-00312: online log 5 thread 1: '/u02/oracle/oradata/testdb/redo05.log'
SQL>

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


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: '/u02/oracle/oradata/testdb/system01.dbf'

Reason and Prerequisites:

In general, the above errors suggest that the redo log is corrupt. A repair for these types of  inconsistencies is not supported. In almost all cases, hardware problems trigger these errors If the process of recovering a redo log terminates with one of the above errors, you can no longer import the subsequent redo logs, for the sake of transaction consistency. In the worst-case scenario, you can only perform a partial recovery before the redo log in question. All subsequent changes then disappear.

If you receive one of the above errors when archiving an online redo log, you can usually solve this problem without any data loss.  In this case, additional errors such as ORA-00255 or ORA-16038 usually occur.

Note 540463 contains information about how to proactively check the redo log consistency.
Note 1016173 describes the redo log validation using RMAN.


My workaround:

SQL> select name,open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
TESTDB    MOUNTED

SQL> col FIRST_CHANGE# format 99999999999999;
SQL>
SQL> select group#,status,archived,sequence#,first_change# from v$log;

    GROUP# STATUS           ARC  SEQUENCE#   FIRST_CHANGE#
---------- ---------------- --- ---------- ---------------
         5 CURRENT          NO       29551    123790176390
         6 ACTIVE           NO       29550    123790099280
         7 INACTIVE         YES          1    120240973534
         8 UNUSED           YES          0               0

SQL>


Do below as per the "status":

1) If 'status' = INACTIVE you are lucky, you can clear the group:

SQL> alter database clear <unarchived> logfile group n;
(use 'unarchived' when 'archived' shows 'NO') .

2) If 'status' = ACTIVE try

SQL> alter database checkpoint;,

if this command executes successfully, logfile gets status INACTIVE and again you can clear the

logfile, if not you have to handle the logfile as CURRENT.

3) If 'status' = CURRENT you must do an incomplete recovery up to the latest usable SCN:



restore database until scn <first_change#_of_current_logfile>;
recover database until scn <first_change#_of_current_logfile>;
alter database open resetlogs;

e.g.,

RMAN> restore database until scn 123790176390;

RMAN> recover database until scn 123790176390;

SQL> alter database open resetlogs;


Note : If issue is not resolved, then restore from fresh backups.