Question on the recovery of online log damage, ITPUB is discussed on http://www.itpub.net/showthread.php?s=&threadid=175996 often encountered this problem, so it is finished, as own Memo: Online logs are classified into current online logs and non-current online logs, and the corruption of non-current online logs is relatively simple, usually to solve the problem through the CLEAR command.
Damage Non-current online log: 1. Start the database, encounter ORA-00312 or ORA-00313 error, such as: ORA-00313: Open failed for Members of log group 4 of thread 1ORA-00312: Online log 3 thread 1: / Opt / ORCL / DB04 / ORADATA / ORCL / DB03.LOG 'From here we know the data files of the log group 1 damage or lose from the alarm file to see more detailed information 2, view v $ log view: SQL> SELECT GROUP #, sequence #, archived, status from v $ log;
Group # sequence # arc status
---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------
1 54 Yes inactive
2 55 no current
3 53 Yes Inactive
It can be known that the group is non-current state and has been archived. 3, rebuild the log file SQL> ALTER DATABASE CLOGFILE Group 3 with clear command; if the log group has not been archived, you need to use SQL> ALTER DATABASE CLEAR UNACHIVED LOGFILE GROUP 3; 4, open the database, re-back up the database SQL> ALTER DATABASE OPEN; Description: 1) If damaged is a non-current online log file, only Clear can only be rebuilt, but if the database is archived, the log is not archived, you need to force CLEAR. 2), it is recommended that CLEAR, especially forced CLEAR as a full backup of a database. 3) This method is suitable for archiving and non-archive databases.
Damage Current Online Log:
There are two cases of damage to the current log in archiving mode. First, the database is normal shutdown, and there is no pending transaction in the log file requires instance recovery. The current log group can be used directly with ALTER DATABASE CLEAR UNACHIVED LOGFILE Group N to rebuild . Second, it is an active business in the log group. The database needs to be recovered. The log group needs to synchronize. There are two remedies A. The best way is to ensure the consistency of the database by incomplete recovery, but this Measures require in archive, and have available backup B. By mandatory recovery, it may cause the database inconsistent. The following is used to illustrate these two recovery methods 5.1.2.1 Recovery by backup 1. Open the database, encounter a similar error ORA-00313: Open failed for members of log group 1 of thread 1OR-00312: Online log 1 Thread 1: 'D: /oracle/oradata/test/redo01.log'ora-27041: Unable to open fileosd-04002: unable to open fileo / s-error: (OS 2) The system cannot find the specified file 2, View v $ log, found is current log SQL> SELECT Group #, sequence #, archived, status from v $ log; group # sequence # archived status ---------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ - - -------- ---------------- 1 1 No Current2 2 Yes inactive3 3 yes inactive3 ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUR 1 * Error At line 1: ORA-01624: LOG 1 Needed for crash recovery of thread 1ORA-00312: Online log 1 thread 1: D: /oracle/oradata/test/redo01.log ' 4, all backup of the copy-effective database, does not completely restore the database to get the most recent SCN method with unsil SCN recovery or use the Until CNACEL Recover Recover Database Until Cancel to select Auto first, try to recover the archive log, and then re-re-re-re-re- Recover Database Until Cancel Enter Cancel this time, complete the incomplete recovery, that is, the recovery twice. Such as: SQL> Recover Database Until Cancel; Auto ... SQL> Recover Database Until Cancel; Cancel; 5, using Alter Database Open RESETLOGS Open Database Description: 1. The database recovered database is consistent incomplete recovery, will lose the current Transaction Data in the online log 2, this method is suitable for archiving the database and has a fully backed up of available databases. 3. After the recovery is successful, remember to make a full backup of a database. 4. It is recommended that the online log file must implement the mirror phase on different disks, avoid this happening, because any data is lost is not allowed for production.