启动备库的过程中出现如下错误：
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 = "'',''" scope=spfile;
If you are using pfile then set the parameter in init file after shutting down the database:
如果使用了pfile，则在文本文件中修改，并重启数据库!
*.log_file_name_convert = '',''
对于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
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22664653/viewspace-707058/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/22664653/viewspace-707058/
1784
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
