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

简介: 启动备库的过程中出现如下错误:ORA-00313: open failed for members of log group 4 of thread 2ORA-00312: online log 4 thread 2: '/opt/oracle/oradata/alifpre/group_4.
启动备库的过程中出现如下错误:
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
相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
SQL 监控 关系型数据库
使用 pt-query-digest 工具分析 MySQL 慢日志
【8月更文挑战第5天】使用 pt-query-digest 工具分析 MySQL 慢日志
881 3
使用 pt-query-digest 工具分析 MySQL 慢日志
|
Go 虚拟化 云计算
Docker 基础知识解析:容器与传统虚拟化对比:资源利用、启动时间、隔离性和部署效率
Docker 基础知识解析:容器与传统虚拟化对比:资源利用、启动时间、隔离性和部署效率
948 0
|
SQL 监控 Oracle
Oracle 性能优化之AWR、ASH和ADDM(含报告生成和参数解读)
Oracle 性能优化之AWR、ASH和ADDM(含报告生成和参数解读)
|
网络协议 Linux 网络安全
Linux命令hostnamectl:掌握系统主机信息的利器
`hostnamectl`是Linux系统管理的关键工具,用于查看和设置主机名、内核信息等。它集成在`systemd`中,通过修改配置文件交互。命令特点包括综合显示多种信息、简单语法和设置功能。例如,`hostnamectl status`显示系统详情,`sudo hostnamectl set-hostname NEWHOSTNAME`用于更改主机名。使用时注意权限、备份配置、更新网络和重启相关服务,避免频繁更改。
PGA memory operation
PGA memory operation
306 1
|
监控 关系型数据库 MySQL
红帽 9 zabbix 安装流程
Zabbix是一个监控软件,用于确保企业服务架构的安全运行,具备灵活的告警机制和分布式监控能力。它由Server、Web页面、数据库、Proxy和Agent五个组件组成。工作流程中,Agent在目标设备上收集数据,Server存储和处理数据,Web页面提供监控信息。Zabbix支持主动和被动两种数据收集模式。在Redhat 9.2环境下,安装包括关闭防火墙、设置SELinux、安装MySQL、创建Zabbix数据库和用户、安装Zabbix RPM包及配置服务。完成安装后,通过Web界面使用Admin账号和预设密码zabbix登录。
664 2
|
存储 数据库 OceanBase
OceanBase数据库的磁盘配置包括数据盘和事务日志盘的大小
OceanBase数据库的磁盘配置包括数据盘和事务日志盘的大小
310 3
|
网络协议 Ubuntu Linux
无公网IP内网穿透使用vscode配置SSH远程ubuntu随时随地开发写代码-2
无公网IP内网穿透使用vscode配置SSH远程ubuntu随时随地开发写代码
|
弹性计算 监控 Oracle
Oracle 21C 使用rpm安装
使用Oracle的rpm安装包安装oracle21C
2621 0
Oracle 21C 使用rpm安装