If LGWR is at least accessible to a member, the write to which accessible to the member will be performed as usual, and the LGWR ignores unavailable members within the group. If the group is inactive, that is, the checkpoint has been completed, then discard and add a new online log member to solve the problem, otherwise, if the group is the current active log group, you must first force the log switching. When Online Redo log has multiple member, an error can be made simple to copy other files that have not been wrong, regenerate the new redo log member, start the database, directly alter system switch logfile is only a certain When there is only one member and there is an error, if it is in the archive mode, you can use the ALTER DATABASE CLEAR LOGFILE GROUP N to recover I use the notepad to open the Redo004 file and modified. Then Alter System Switch logfile, until Group 4, then the database error is restarted, then the database cannot open; you can use ALTER DATABASE CLOGFILE Group N (or with ALTER DATABASE CLEAR UNACHIVED LOGFILEGROUP N) to solve this problem. : SQL> ALTER DATABASE CLOGFILE GROUP 4;
Database altered.
SQL> SELECT * FROM V $ log;
Group # thread # sequence # bytes Members Arc Status first_change # first_tim ----------------------------------- --- ---------- --------------------- ---- 1 1 2 104857600 1 no inactive 3165543 04-NOV-04 2 1 1 104857600 1 no inactive 3161864 04-NOV-04 3 1 3 104857600 1 no invalidated 3165547 04-NOV-04 4 1 0 1048576 1 yes unused 0
SQL> ALTER DATABASE OPEN; DATABASE Altered.
SQL> SELECT * FROM V $ logfile;
Group # status type member ---------- --------------------------------------------------------------------------------------------- -------------------------------------------------- ---- 3 Stale Online F: /oracle/oradata/oracas/redo03.log 2 Online F: /oracle/oradata/oracas/redo02.log 1 Online F: /oracle/oradata/oracas/redo01.log 4 Online F : /Oracle/oradata/oracas/redo04.logsql> SELECT * from V $ log;
Group # thread # sequence # bytes Members Arc Status first_change # first_tim ----------------------------------- --- ---------- --------------------- ---- 1 1 2 104857600 1 no inactive 3165543 04-NOV-04 2 1 1 104857600 1 no inactive 3161864 04-NOV-04 3 1 3 104857600 1 NO inactive 3165547 04-NOV-04 4 1 4 1048576 1 NO CURRENT 3185619 04-NOV-04 This is found that the database is normal, ^ _ ^
