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

启动备库的过程中出现如下错误:
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/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值