DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证

本篇文档学习,DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证

1.取消MRP进程

备库查询进程状态
select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS
--------- -------- ---------- ------------ ---------- ----------
ARCH ARCH 0 CONNECTED 0 0
ARCH ARCH 0 CONNECTED 0 0
ARCH ARCH 0 CONNECTED 0 0
ARCH ARCH 0 CONNECTED 0 0
RFS UNKNOWN 0 IDLE 0 0
RFS UNKNOWN 0 IDLE 0 0
MRP0 N/A 1124 WAIT_FOR_LOG 0 0

WAIT_FOR_LOG --等待日志传输,说明当前MRP进程应用归档文件进行介质恢复

取消MRP进程应用

alter database recover managed standby database cancel;

select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby where PROCESS like ‘%M%‘;

no rows selected

2.启用Foreground recovery session MR(fg),前台恢复进程应用归档文件进行恢复
启用MRP进程,应用归档进行进行恢复

[email protected] >recover managed standby database;

查询MRP进程状态

PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS
--------- -------- ---------- ------------ ---------- ----------
MR(fg) N/A 1126 APPLYING_LOG 58451 86733 --前台等待状态,应用归档日志

WAIT_FOR_LOG - 进程正在等待归档的重做日志完成

WAIT_FOR_GAP - 进程正在等待解决存档差距

APPLYING_LOG - 进程正在将归档的重做日志主动应用于备用数据库

查询归档进程状态

select dest_name,status,recovery_mode from v$archive_dest_status where dest_name=‘LOG_ARCHIVE_DEST_1‘;
DEST_NAME STATUS RECOVERY_MODE
---------------------------------------- --------- -----------------------
LOG_ARCHIVE_DEST_1 VALID MANAGED (Managed recovery is active)应用归档日志

--查询当前已归档的最大归档文件序列号
[email protected] >select max(sequence#),thread# from v$archived_log group by thread#;
MAX(SEQUENCE#) THREAD#
-------------- ----------
1162 1

--再次查询MRP进程状态,WAIT_FOR_LOG,
MR(fg) N/A 1163 WAIT_FOR_LOG 0 0

小结:如下命令直接启用MR进程,会话不断开,最初MR进程,Foreground recovery session,进程状态最初APPLYING_LOG,应用归档日志,随后归档日志应用完毕后,进程处于等待WAIT_FOR_LOG状态,等待主库传输归档
recover managed standby database;

3.启用MRP进程,后台恢复进程应用归档文件进行恢复

alter database recover managed standby database cancel;

recover managed standby database disconnect from session;

select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby where PROCESS like ‘%M%‘;

PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS
--------- -------- ---------- ------------ ---------- ----------
MRP0 N/A 1163 WAIT_FOR_LOG 0 0

--进程为MRP0进程, 处于WAIT_FOR_LOG 等待主库传输归档状态

查询归档进程状态

select dest_name,status,recovery_mode from v$archive_dest_status where dest_name=‘LOG_ARCHIVE_DEST_1‘;

DEST_NAME STATUS RECOVERY_MODE
---------------------------------------- --------- ----------
LOG_ARCHIVE_DEST_1 VALID MANAGED

4.启用Foreground recovery session MR(fg),前台恢复进程应用standby redo logfile进行恢复
alter database recover managed standby database cancel;

--启用MR前台恢复进程

alter database recover managed standby database using current logfile;

or

recover managed standby database using current logfile; --等价

--查询进程状态,APPLYING_LOG
select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby where PROCESS like ‘%M%‘;
PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS
--------- -------- ---------- ------------ ---------- ----------
MR(fg) N/A 1169 APPLYING_LOG 202 203

查询归档进程状态
select dest_name,status,recovery_mode from v$archive_dest_status where dest_name=‘LOG_ARCHIVE_DEST_1‘;
DEST_NAME STATUS RECOVERY_MODE
--------------------------------------- --------- -----------------------
LOG_ARCHIVE_DEST_1 VALID MANAGED REAL TIME APPLY

查询standby 状态发现
select group#,thread#,sequence#,bytes/1024/1024 m,blocksize,status from v$standby_log;
GROUP# THREAD# SEQUENCE# M BLOCKSIZE STATUS
---------- ---------- ---------- ---------- ---------- ----------
11 1 1172 50 512 ACTIVE
12 1 0 50 512 UNASSIGNED
13 1 0 50 512 UNASSIGNED

5.启用MRP 进程,后台恢复进程应用standby redo logfile进行恢复

recover managed standby database using current logfile disconnect;
or
alter database recover managed standby database using current logfile disconnect;

--主库查询
select DEST_NAME,STATUS,TRANSMIT_MODE,NET_TIMEOUT from v$archive_dest;
DEST_NAME STATUS TRANSMIT_MOD NET_TIMEOUT
---------------------------------------- --------- ------------ -----------
LOG_ARCHIVE_DEST_1 VALID SYNCHRONOUS 0
LOG_ARCHIVE_DEST_2 VALID PARALLELSYNC 30 --并行同步数据

--备库查询
select dest_name,status,recovery_mode from v$archive_dest_status;
DEST_NAME STATUS RECOVERY_MODE
---------------------------------------- --------- -----------------------
LOG_ARCHIVE_DEST_1 VALID MANAGED REAL TIME APPLY

--进程状态MRP进程
select process,client_process,sequence#,status,BLOCK#,BLOCKS from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS BLOCK# BLOCKS
--------- -------- ---------- ------------ ---------- ----------
MRP0 N/A 1172 APPLYING_LOG 1272 102400

总结:备库应用恢复有四种状态
MRP0 后台 应用归档 or 应用standby redo log
MR((fg) 前台 应用归档 or 应用standby redo log

什么是前台,后台,前台进程,会话断开,进程关闭
什么时候开启前台进程MR,什么时候开启后台MRP0进程
在执行程命令时,未加入disconnect参数,会话不断开,及开启MR前台进程

MRP0进程应用归档,v$managed_standby视图中status为何还存在APPLYING_LOG?
APPLYING_LOG,只是说明了进程正在应用归档,并非标识MRP0进程是否实时应用

如何查询,是否实时应用?
select dest_name,status,recovery_mode from v$archive_dest_status;
recovery_mode=MANAGED REAL TIME APPLY

开启实时应用的前提条件
1.数据库版本>10g
2.需要提取创建standby redo logfile

原文地址:https://www.cnblogs.com/lvcha001/p/9592074.html

时间: 2024-11-10 04:17:42

DG备库,实时应用如何判断,MR进程,及MRP应用归档,三种情况的查询及验证的相关文章

ORA-21561、ORA-15055、ORA-25253 导致DG备库无法应用归档

昨天去某客户那里做巡检,顺便看一下上次搭建的RAC-DG环境是否正常,不看不知道,一看吓一跳,上次的DG是8月20日运行的,而DG备库从8月31日之后实例就没有开启过,后来询问后才得知,原来那天断过一次电,后来重启了机器.直到今天我过去了,才把实例启动起来.也就是说,从8月31日到今天快1个月的时间,备库一致处于未使用状态. 接着查看备库归档,显然已经缺失了很多了,tnread1 最后一个日志为1661,tnread2 最后一个日志为1324,而此时主库中还保留的最早的日志是9月8日的,thre

模拟主库创建数据文件,dg备库空间不足时问题处理

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

使用JavaScript判断图片是否加载完成的三种实现方式

有时需要获取图片的尺寸,这需要在图片加载完成以后才可以.有三种方式实现,下面一一介绍. 一.load事件 <!DOCTYPE HTML> <html> <head> <meta charset="utf-8"> <title>img - load event</title> </head> <body> <img id="img1" src="http:/

JavaScript判断图片是否加载完成的三种方式

一.load事件 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <!DOCTYPE HTML> <html> <head>     <meta charset="utf-8">     <title>img - load event</title> </head> <body>     <img id="img1" src=&qu

sharepoint 判断用户是否存在某个组中三种方法

1.思路:查找用户所有的组来匹配是否在特定的组(推荐) 不用担心组不存在而报错. public static bool IsUserMemberOfGroup(SPUser user, string groupName) { bool result = false; if (!String.IsNullOrEmpty(groupName) && user != null) { foreach (SPGroup group in user.Groups) { if (group.Name =

JavaScript判断图片是否加载完成的三种方式---转

JavaScript判断图片是否加载完成的三种方式 有时需要获取图片的尺寸,这需要在图片加载完成以后才可以.有三种方式实现,下面一一介绍. 一.load事件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <!DOCTYPE HTML> <html> <head>     <meta charset="utf-8">     <title>img - load event</title>

DG备库磁盘空间满导致无法创建归档

上周五去某客户那里做数据库巡检,是window 2008系统上10g的一套NC系统的库,已经配置了DG,但是巡检时发现数据库报错: Tue Nov 11 10:13:57 2014 LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2 Tue Nov 11 10:14:29 2014 Errors in file d:\oracle\product\10.2

做dg备库执行duplicate target database for standby nofilenamecheck报RMAN-06023

RMAN duplicate for standby失败解决过程在用rman duplicate to standby 生成备库的时候总是不成功,多次尝试均是下面的错误:RMAN> duplicate target database for standby nofilenamecheck;Starting Duplicate Db at 16-JAN-2013 12:22:45using target database control file instead of recovery catal

oracle dg 备库不同步主库数据

今天遇到一个数据库同步问题,主库被关闭,重启主库后,备库不能正常同步主库数据.只有当手动切换归档日志的时候,备库才能和主库一致. 这个问题的解决方法: 重启备库,重新应用归档日志. 操作步骤如下: //关闭备库监听器 lsnrctl stop //关闭备库 sqlplus / as sysdba alter database recover managed standby database cancel; shutdown immediate; //启动备库 startup nomount; a