啟動備庫的過程中出現如下錯誤：

ORA-00313: open failed for members of log group 4 of thread 2

ORA-00312: online log 4 thread 2: '/opt/oracle/oradata/alifpre/group_4.260.761070481'

ORA-27037: unable to obtain file status

原因：

備庫上缺少聯機重做日誌

解決方法：

可以忽略此錯誤，因為聯機重做日誌會在switch over 或者 failover的時候自動建立！

If you want to fix these messages then please use following steps:

也可以執行如下步驟來解決此問題：

1 如果主庫和備庫的日誌歸檔位置不一樣，檢查和設定log_file_name_convert 引數。

SQL> alter system set log_file_name_convert = "'<location on primary>','<location on standby>'" scope=spfile;

If you are using pfile then set the parameter in init file after shutting down the database:

如果使用了pfile，則在文字檔案中修改，並重啟資料庫!

*.log_file_name_convert = '<location on primary>','<location on standby>'

對於10.2 版本的，不過日誌的位置是否一樣，都要設定，否則會遇到 ORA-19527和ORA-312

2. 取消備庫的日誌應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3 執行如下命令清空備庫上所有的日誌組

SQL>alter database clear logfile group 1;

4 檢查v$log 檢視確認日誌檔案的狀態和大小

SQL> select group#,thread#,bytes/1024/1024 mb ,status from v$log;

GROUP# THREAD# MB STATUS

---------- ---------- ---------- ---------------

1 1 50 CURRENT

2 1 50 INACTIVE

3 2 50 INACTIVE

4 2 50 CURRENT

5 只有在備庫日誌也丟失的情況下，重建備庫日誌

a 刪除standby 日誌，檢查v$standby_log

SQL> alter database drop standby logfile group 4;

b 重建備庫日誌組：

SQL> alter database add standby logfile group 4 ('/opt/oracle/oradata/yandb/stby01.log') size 50m;

以上是官方文件的方法。

我犯的錯誤是：

在主庫

alter system set log_archive_dest_2='SERVICE=alifpre ARCH SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=alifpre' scope=spfile sid='*';

show parameter log_archive_dest log_archive_dest_2沒有值：

SQL> show parameter log_archive_dest

NAME TYPE VALUE

---------------- ---------------------------------

log_archive_dest string

log_archive_dest_1 string

LOCATION=/opt/rac/oracle/arch

log_archive_dest_2 string --空

SQL> alter system set log_archive_dest_2='SERVICE=alifpre ARCH SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=alifpre' scope=spfile sid='*';

System altered.

SQL> show parameter log_archive_dest_2

NAME TYPE VALUE

-------------------- -------------------------

log_archive_dest_2 string --空

log_archive_dest_20 string

log_archive_dest_21 string

log_archive_dest_22 string

log_archive_dest_23 string

log_archive_dest_24 string

log_archive_dest_25 string

log_archive_dest_26 string

log_archive_dest_27 string

log_archive_dest_28 string

log_archive_dest_29 string

SQL> alter system set log_archive_dest_2='SERVICE=alifpre ARCH SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=alifpre' scope=both sid='*';

System altered.

SQL> show parameter log_archive_dest_2

NAME TYPE VALUE

--------------------------------------------------------------------

log_archive_dest_2 string SERVICE=alifpre ARCH SYNC VA

LID_FOR=(ONLINE_LOGFILES,PRIM

ARY_ROLE) DB_UNIQUE_NAME=alifpre

log_archive_dest_20 string

log_archive_dest_21 string

log_archive_dest_22 string

log_archive_dest_23 string

log_archive_dest_24 string

log_archive_dest_25 string

log_archive_dest_26 string

log_archive_dest_27 string

log_archive_dest_28 string

log_archive_dest_29 string

SQL>

SQL> alter system set log_archive_dest_state_2=enable scope=both sid='*';

System altered.

SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(rac,alifpre)' scope=both sid='*';

SQL> alter system set STANDBY_ARCHIVE_DEST='location=/opt/rac/oracle/arch' scope=both sid='*';

System altered.

備庫日誌：成功應用歸檔日誌！

alter database recover managed standby database disconnect from session

Attempt to start background Managed Standby Recovery process (yangdb)

Thu Sep 08 19:25:33 2011

MRP0 started with pid=24, OS id=18407

MRP0: Background Managed Standby Recovery process started (yangdb)

Serial Media Recovery started

Managed Standby Recovery not using Real Time Apply

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Media Recovery Waiting for thread 1 sequence 53

Completed: alter database recover managed standby database disconnect from session

Thu Sep 08 19:26:02 2011

RFS[1]: Assigned to RFS process 18409

RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 18933

RFS[1]: Opened log for thread 1 sequence 53 dbid -1945915091 branch 761070192

Thu Sep 08 19:26:03 2011

RFS[2]: Assigned to RFS process 18411

RFS[2]: Identified database type as 'physical standby': Client is ARCH pid 18929

RFS[2]: Opened log for thread 1 sequence 55 dbid -1945915091 branch 761070192

Thu Sep 08 19:26:03 2011

RFS[3]: Assigned to RFS process 18413

RFS[3]: Identified database type as 'physical standby': Client is ARCH pid 18935

RFS[3]: Opened log for thread 1 sequence 54 dbid -1945915091 branch 761070192

Thu Sep 08 19:26:08 2011

RFS[4]: Assigned to RFS process 18416

RFS[4]: Identified database type as 'physical standby': Client is ARCH pid 25846

Archived Log entry 9 added for thread 1 sequence 53 rlc 761070192 ID 0x8c044d2a dest 2:

Thu Sep 08 19:26:08 2011

Media Recovery Log /opt/oracle/arch/yangdb1_53_761070192.log

Thu Sep 08 19:26:08 2011

RFS[5]: Assigned to RFS process 18418

RFS[5]: Identified database type as 'physical standby': Client is ARCH pid 25838

Thu Sep 08 19:26:08 2011

RFS[6]: Assigned to RFS process 18420

RFS[6]: Identified database type as 'physical standby': Client is ARCH pid 25848

RFS[4]: Opened log for thread 2 sequence 47 dbid -1945915091 branch 761070192

Archived Log entry 10 added for thread 1 sequence 54 rlc 761070192 ID 0x8c044d2a dest 2:

Media Recovery Log /opt/oracle/arch/2_43_761070192.dbf

RFS[5]: Opened log for thread 2 sequence 49 dbid -1945915091 branch 761070192

RFS[6]: Opened log for thread 2 sequence 48 dbid -1945915091 branch 761070192

Archived Log entry 11 added for thread 2 sequence 47 rlc 761070192 ID 0x8c044d2a dest 2:

Archived Log entry 12 added for thread 2 sequence 48 rlc 761070192 ID 0x8c044d2a dest 2:

Archived Log entry 13 added for thread 2 sequence 49 rlc 761070192 ID 0x8c044d2a dest 2:

RFS[5]: Opened log for thread 2 sequence 46 dbid -1945915091 branch 761070192

RFS[1]: Opened log for thread 1 sequence 56 dbid -1945915091 branch 761070192

Archived Log entry 14 added for thread 2 sequence 46 rlc 761070192 ID 0x8c044d2a dest 2:

RFS[4]: Opened log for thread 2 sequence 45 dbid -1945915091 branch 761070192

Archived Log entry 15 added for thread 1 sequence 55 rlc 761070192 ID 0x8c044d2a dest 2:

RFS[6]: Opened log for thread 2 sequence 44 dbid -1945915091 branch 761070192

Archived Log entry 16 added for thread 2 sequence 45 rlc 761070192 ID 0x8c044d2a dest 2:

Archived Log entry 17 added for thread 2 sequence 44 rlc 761070192 ID 0x8c044d2a dest 2:

RFS[3]: Opened log for thread 1 sequence 57 dbid -1945915091 branch 761070192

RFS[2]: Opened log for thread 1 sequence 58 dbid -1945915091 branch 761070192

Media Recovery Log /opt/oracle/arch/yangdb2_44_761070192.log

Thu Sep 08 19:26:13 2011

Archived Log entry 18 added for thread 1 sequence 56 rlc 761070192 ID 0x8c044d2a dest 2:

Archived Log entry 19 added for thread 1 sequence 57 rlc 761070192 ID 0x8c044d2a dest 2:

Media Recovery Log /opt/oracle/arch/yangdb2_45_761070192.log

Media Recovery Log /opt/oracle/arch/yangdb2_46_761070192.log

Media Recovery Log /opt/oracle/arch/yangdb1_54_761070192.log

Media Recovery Log /opt/oracle/arch/yangdb2_47_761070192.log

【DataGuard】ORA-00313, ORA-00312, ORA-27037 in Standby Database

相關文章