Mandalika's scratchpad [ Work blog @Oracle | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14  11.14  12.14  01.15  02.15  03.15  04.15  06.15  09.15  12.15  01.16  03.16  04.16  05.16  06.16  07.16  08.16  09.16  12.16  01.17  02.17  03.17  04.17  06.17  07.17  08.17  09.17  10.17  12.17  01.18  02.18  03.18  04.18  05.18  06.18  07.18  08.18  09.18  11.18  12.18  01.19  02.19  05.19  06.19  08.19  10.19  11.19  05.20  10.20  11.20  12.20  09.21  11.21  12.22 


Thursday, January 04, 2007
 
Oracle: Lost Redo Log

Scenario:

The disk that is holding the most up-to-date redo log files experienced a fatal failure, and the database wouldn't come up any more. It complains about missing redo logs. So, you copy the redo log files from a recent backup; but still the database won't come up with error messages like ORA-00314: log 1 of thread 1, expected sequence# doesn't match.

SQL> startup
ORACLE instance started.

Total System Global Area 4294967296 bytes
Fixed Size 1306568 bytes
Variable Size 2534150200 bytes
Database Buffers 1728053248 bytes
Redo Buffers 31457280 bytes
Database mounted.
ORA-00314: log 1 of thread 1, expected sequence# doesn't match
ORA-00312: online log 1 thread 1: '/opt/oracle/oradata_4/RedoLogFiles/log1.dbf'

How to bring up the database with no redo logs?

In production environments, usually archive logging will be turned on. If that's the case, consult the Oracle system administration documentation to restore the lost transactions.

In all other cases it is very unlikely to recover the lost transactions. So the easiest way to bring up the database is to rebuild the control file. The steps to rebuild the control file with new redo log files are as follows:
  1. Start the database up.

    SQL> startup <- let it complain about online redo log


  2. Run the following command to dump the control file into a trace file.
    SQL> alter database backup controlfile to trace;
    Database altered.

    Go to udump location and locate the file which contains the necessary SQL text to build the control file. The easiest way is to grep for text like 'CREATE CONTROLFILE REUSE DATABASE'. Once you locate the trace file, change the extension from trc to sql and change NORESETLOGS to RESETLOGS. That is, a SQL like:

    CREATE CONTROLFILE REUSE DATABASE "XYZ" NORESETLOGS NOARCHIVELOG

    should be changed to

    CREATE CONTROLFILE REUSE DATABASE "XYZ" RESETLOGS NOARCHIVELOG

    Remove the lines starting from the line "RECOVER DATABASE USING BACKUP CONTROLFILE" to the end.


  3. Shut down the database


  4. Add the parameter _allow_resetlogs_corruption=TRUE to the init.ora file.


  5. Run the script that you just modified -- it creates a new control file.


  6. Shut down the database one more time


  7. Start the database instance by running startup command as sysdba. It may fail with the error ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


  8. Open the database with by running alter database open resetlogs;. Redo log files will be automatically created in this step.


  9. Shutdown the database, remove the parameter _allow_resetlogs_corruption=TRUE from the init.ora file and restart the database instance. If the instance comes up fine, shut it down and take a backup. Otherwise, check the alert messages carefully and act accordingly to fix the things up.



Acknowledgements:
Akiko Marti

________________
Technorati tags:



Comments: Post a Comment



<< Home


2004-2019 

This page is powered by Blogger. Isn't yours?