處理Online redo log錯誤

1：redo log 是如何工作的：

Online redo logs store a record of transactions that have occurred in your database. Online redo logs exist solely to provide a mechanism for you to recover your database in the event of a failure. You are required to have at least two online redo log groups in your database. Each online redo log group must contain at least one online redo log member. The member is the physical file that exists on disk. You can create multiple members in each redo log group, which is known as multiplexing your online redo log group.

NOTE：聯機重做日誌記錄數據庫發生的所有變化。聯機重做日誌採用循環些的處理方法

2：如何儘量減少redo錯誤造成的數據損失：

•Multiplex groups to have multiple members.

•Never allow two members of the same group to share the same controller.
•Never put two members of the same group on the same physical disk.
•Ensure operating system file permissions are set appropriately.
•Use physical storage devices that are redundant (that is, RAID).
•Appropriately size the log files so that they switch and are archived at regular intervals.
•Set the  archive_lag_targetinitialization parameter to ensure that the online redo logs

are switched at regular intervals

3：Determining How to Restore

•  Inspect the alert.log file to determine which online redo log files have experienced a media failure.
•  Query V$LOG and V$LOGFILE to determine the status of the log group and degree of multiplexing.
•  If  there is still one functioning member of a multiplexed group, fix the remaining failed member(s).
•  Depending on the status of the log group

select a.group#,a.thread# ,a.status ,b.member member,b.status from v$log a,v$logfile b where a.group#=b.group# order by a.group#,b.group#；

聯機重做日誌的狀態：

CURRENT                               The log group that is currently being written to by the log writer.---當前正在使用
ACTIVE                                     The log group is required for crash recovery and may or may not have been archived.--用來crash恢復，有可能已經歸檔
CLEARING                              The log group is being cleared out by an  alter database clear  logfile command.--
CLEARING_CURRENT        The current log group is being cleared of a closed thread.
INACTIVE                                 The log group isn’t needed for crash recovery and may or may not have  been archived.
UNUSED                                   The log group has never been written to; it was recently created.

4： Restoring After Losing One Member of the  Multiplexed Group

現象：

Errors in file /oracle/admin/purple/bdump/purple_lgwr_4645.trc:
ORA-00321: log 2 of thread 1, cannot update log file header
ORA-00312: online log 2 thread 1: '/oracle/oradata/purple/redo02.log'

解決：

SQL> alter system archive log  current; --將發生錯誤的組狀態置於NO CURRENT 
SQL> alter database drop logfile member '/oracle/oradata/purple/redo02.log';
SQL> alter database add logfile member '/oracle/oradata/purple/redo02.log' to group 2;
Database altered.

5：Recovering After Loss of All Members of the INACTIVE  Redo Log Group

[oracle@oracle10g purple]$ rm -rf redo02*

alter system archive log current
*
ERROR at line 1:
ORA-16038: log 2 sequence# 27 cannot be archived
ORA-00312: online log 2 thread 1: '/oracle/oradata/purple/redo021.log'
ORA-00312: online log 2 thread 1: '/oracle/oradata/purple/redo02.log'

解決：

SQL> alter database clear logfile group 2;
SQL> alter database clear unarchived logfile group 2;
SQL> alter database drop logfile group 2；
SQL> alter database add logfile group 2 ('/oracle/oradata/purple/redo02.LOG', '/oracle/oradata/purple/redo021.log') SIZE 50M;

Database altered.

6:Recovering After Loss of All Members of the ACTIVE  Redo Log Group

SQL>alter system checkpoint

SQL> alter database clear logfile group 2;
SQL> alter database clear unarchived logfile group 2;
SQL> alter database drop logfile group 2；

SQL> alter database add logfile group 2 ('/oracle/oradata/purple/redo02.LOG', '/oracle/oradata/purple/redo021.log') SIZE 50M;

7:Recovering After Loss of All Members of the CURRENT Redo Log Group

•Perform an incomplete recovery up to the last good SCN.
•If flashback is enabled, flash your database back to the last good SCN.
•If you’re using Oracle Data Guard, fail over to your physical or logical standby database.
•Contact Oracle Support for suggestions

SQL> shutdown immediate;
SQL> startup mount;
SQL> select group#, status, archived, thread#, sequence#, first_change# from v$log;

    GROUP# STATUS           ARC    THREAD#  SEQUENCE# FIRST_CHANGE#
---------- ---------------- --- ---------- ---------- -------------
         1 INACTIVE         YES          1         26        568581
         3 CURRENT          NO           1         28        568588
         2 UNUSED           YES          1          0             0

RMAN> restore database until scn 568588;
RMAN> recover database until scn 568588;
RMAN> alter database open resetlogs;

RMAN> list incarnation;


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       PURPLE   2860377939       PARENT  1          22-OCT-05
2       2       PURPLE   2860377939       PARENT  525876     18-JAN-13
3       3       PURPLE   2860377939       CURRENT 568582     21-JAN-13