【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
ORACLE RAC集群 RMAN自动备份controlfile失败之ORA-00245&ORA-27037     近期oracle数据库巡检中，广州汕头一RAC集群有告警日志显示RMAN自动备份控制文件失败，原因是控制文件自动备份打开并且备份目录在本地，涉及的备份目录只在节点2上有，而在节点1上没有，导致控制文件自动备份失败！     操作系统：RHEL6.
关于ORACLE IMPDP 报错ORA-29913 ORA-31693 ORA-01861的原因 导入语句如下： impdp system/ Nnrjt$739rt  job_name=sec_dmp tables=seccore.syn_event remap_schema=seccore:sechis dumpfile=BAK:expdp_20160523.