oracle rfs进程过多,Oracle物理备库RFS进程消失,不能启动--解决
今天在测试Oracle环境上做热备,发现RFS进程不存在,做了如下操作后,还是不行:
1、拷贝主库的密码文件到备库
2、重启备库,也重启了主库,并alter system switch logfile;切换日志
3、未发现主库与备库的gap,监听也正常
备库似乎一切正常,但是就是RFS进程不存在,主库的归档日志没有传输到备库
倒是在备库里有个错误提示:
Sun May 25 21:24:09 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_2596.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
查看跟踪文件
[oracle@sdk32 dbs]$ more /oracle/admin/dbcc/bdump/dbcc_mrp0_2596.trc
/oracle/admin/dbcc/bdump/dbcc_mrp0_2596.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: sdk32
Release: 2.6.32-279.el6.i686
Version: #1 SMP Fri Jun 22 10:59:55 UTC 2012
Machine: i686
Instance name: dbcc
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 2596, image: oracle@sdk32 (MRP0)
*** SERVICE NAME:() 2014-05-25 21:13:39.499
*** SESSION ID:(153.1) 2014-05-25 21:13:39.499
ARCH: Connecting to console port...
*** 2014-05-25 21:13:39.500 62692 kcrr.c
MRP0: Background Managed Standby Recovery process started
*** 2014-05-25 21:13:44.500 1118 krsm.c
Managed Recovery: Initialization posted.
*** 2014-05-25 21:13:44.500 62692 kcrr.c
Managed Standby Recovery not using Real Time Apply
Recovery target incarnation = 2, activation ID = -1741977668
Influx buffer limit = 11227 (50% x 22455)
Successfully allocated 2 recovery slaves
Using 543 overflow buffers per recovery slave
Start recovery at thread 1 ckpt scn 15793487 logseq 872 block 2
*** 2014-05-25 21:13:44.579
Media Recovery add redo thread 1
*** 2014-05-25 21:13:44.579 1118 krsm.c
Managed Recovery: Active posted.
*** 2014-05-25 21:13:44.587 62692 kcrr.c
Media Recovery Waiting for thread 1 sequence 872
*** 2014-05-25 21:24:09.713
*** 2014-05-25 21:24:09.713 62692 kcrr.c
MRP0: Background Media Recovery cancelled with status 16037
ORA-16037: user requested cancel of managed recovery operation
*** 2014-05-25 21:24:09.713
Media Recovery drop redo thread 1
*** 2014-05-25 21:24:11.179 1118 krsm.c
Managed Recovery: Not Active posted.
ORA-16037: user requested cancel of managed recovery operation
ARCH: Connecting to console port...
*** 2014-05-25 21:24:11.182 62692 kcrr.c
MRP0: Background Media Recovery process shutdown
*** 2014-05-25 21:24:11.182 1118 krsm.c
查了下对应的ORA错误资料,也未见特别的说明。
于是检查下主库参数:
SQL> show parameter log_archive_dest_state_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string defer
为什么这个参数被设置为了defer,原来是之前做了测试忘改回来了
SQL> ALTER system SET log_archive_dest_state_2 = 'enable';
系统已更改。
SQL> show parameter log_archive_dest_state_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string enable
改回来后,备库alert日志立马开始响应,RFS进程起来了:
Sun May 25 21:54:32 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 2816
RFS[1]: Identified database type as 'physical standby'
Sun May 25 21:54:32 2014
RFS LogMiner: Client disabled from further notification
RFS[1]: Archived Log: '/archive/1_876_847917566.dbf'
RFS[1]: Archived Log: '/archive/1_877_847917566.dbf'
RFS[1]: Archived Log: '/archive/1_878_847917566.dbf'
Sun May 25 21:54:35 2014
Fetching gap sequence in thread 1, gap sequence 875-875
Sun May 25 21:54:45 2014
RFS[1]: Archived Log: '/archive/1_879_847917566.dbf'
Sun May 25 21:54:58 2014
RFS[1]: Archived Log: '/archive/1_880_847917566.dbf'
Sun May 25 21:55:11 2014
RFS[1]: Archived Log: '/archive/1_881_847917566.dbf'
Sun May 25 21:55:24 2014
RFS[1]: Archived Log: '/archive/1_882_847917566.dbf'
Sun May 25 21:55:36 2014
RFS[1]: Archived Log: '/archive/1_883_847917566.dbf'
Sun May 25 21:55:49 2014
RFS[1]: Archived Log: '/archive/1_884_847917566.dbf'
Sun May 25 21:56:04 2014
RFS[1]: Archived Log: '/archive/1_885_847917566.dbf'
Sun May 25 21:56:18 2014
RFS[1]: Archived Log: '/archive/1_886_847917566.dbf'
Sun May 25 21:56:31 2014
RFS[1]: Archived Log: '/archive/1_887_847917566.dbf'
最后再次检查主库与备库的同步情况
主库查询归档日志切换情况:
SQL> select group#,sequence#,status,first_time,to_char(first_change#) as begin_scn
from v$log order by group# asc;
GROUP# SEQUENCE# STATUS FIRST_TIME BEGIN_SCN
---------- ---------- ---------------- -------------- ----------------------------------------
1 898 CURRENT 25-5月 -14 16021321
2 896 INACTIVE 25-5月 -14 15926616
3 897 ACTIVE 25-5月 -14 15973241
备库查询归档日志切换情况:
SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby order by 1,4;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MRP0 WAIT_FOR_LOG 1 898 0 0
RFS IDLE 0 0 0 0
OK,由于部署了一些测试应用,归档日志已经从刚开始时候的878切换到了898
总结:遇到问题要冷静思考可能的原因,Oracle10g的Dataguard还算是比较稳定的,注意检查核心的参数是否有变化。
oracle rfs进程过多,Oracle物理备库RFS进程消失,不能启动--解决相关推荐
- oracle dg fal client,创建物理备库(DG)及相关参数解释
此文默认你会使用dbca创建数据库,并了解数据库的相关目录结构及spfile.file.密码文件等位置. 1.创建主数据库 使用一dbca创建数据主库,sid为dg1,数据库名为dg,并且设置db_u ...
- Oracle 11g Dataguard 物理备库配置(一)之Duplicate配置
Oracle 11g Dataguard Duplicate物理备库配置(一)之物理备库创建配置 # ver:1.5 第五次修改 # modify: 2013.8.16 # author: koumm ...
- oracle dataguard in-memory,Oracle 11g Dataguard 物理备库配置(一)之Duplicate配置
Oracle 11g Dataguard Duplicate物理备库配置(一)之物理备库创建配置 # ver:1.5 第五次修改 # modify: 2013.8.16 # author: koumm ...
- Oracle 11g Dataguard 物理备库配置(三)之Dataguard broker配置
Oracle 11g Dataguard 物理备库配置系列文档 Oracle 11g Dataguard 物理备库配置(一)之duplicate创建 Oracle 11g Dataguard 物理备库 ...
- ORACLE DG专题3--手把手部署DG 物理备库
前言 笔者前文已介绍了ORACLE DG的成员身份与数据保护模式等相关理论知识,从本文开始,将进入ORACLE DG理论与实践相结合模式,深入理解ORACLE DG的内在原理与基本运维技能.本文讲述如 ...
- 图解Oracle 11g physical standby Rolling Upgrade物理备库滚动升级特性
图解Oracle 11g physical standby Rolling Upgrade物理备库滚动升级特性 11g Rolling Database Upgrades Using Transien ...
- Oracle 11g Dataguard 物理备库配置(四)之broker snapshot standby测试
Oracle 11g Dataguard 物理备库配置系列文档 Oracle 11g Dataguard 物理备库配置(一)之duplicate创建 Oracle 11g Dataguard 物理备库 ...
- oracle rfs进程过多,oracle 11g data guard 中RFS、MRP进程的说明
下面是主备库进程的一张关联图 RFS(remote file server):运行在备库上的进程,用于在备库上进行主库的日志恢复.默认,这个进程用于接收从主库传送过来的归档日志. 当物理备库启用了 R ...
- Oracle 11g Data Guard 物理备库快速配置指南(下)
第二部分 作者介绍 作者 Jed Walker 是科罗拉多 Centennial Comcast 媒体中心的数据操作经理(Manager of Databse Operation).他从1997年开始 ...
最新文章
- 抢占式优先权调度算法
- 图解排序算法之3种简单排序(选择,冒泡,直接插入)
- 识别哈希算法类型hash-identifier
- Servlet开发(二)
- wtl单文档选项_Vue3 文档阅读 —— TypeScript 支持
- Hadoop基础--HDFS/Yarn/MapReduce概述
- AD域控exchange邮箱(一)——批量安装MSI安装包
- Win7 下安装ubuntu14.04双系统
- Arcgis地理加权回归
- matlab中如何分布运行,matlab安装、运行与其他问题集锦
- 007.复原 IP 地址
- 数据库连接数和数据库连接池的连接数区别?
- 计算机重启恢复系统怎么操作,电脑如何恢复出厂设置 电脑开机怎么一键还原...
- 二层交换、三层交换和路由的原理及区别
- win 8 store app 圆通快递查询 隐私声明
- 2022电赛声源定位(基础篇)
- 嵌入式系统下Microwindows的实现
- Unity可自定义loading页的异步加载工具,免费下载,使用说明
- 项目开发总结报告 模板
- 有未经处理的异常: Microsoft C++ 异常: cv::Exception,位于内存位置 0x0000006A6311F318 处。