MRP的各种问题及处理 REDO不应用 DG延时 等

物理 standby 数据库应用的日志 sequence# 不再增加，或者 MRP 卡住不再应用任何日志，改如何分析？

先做个初步处理

1.看mrp是否存在ps -ef |grep -i mrp，卡在哪个日志
select process, thread#, sequence#, status from v$managed_standby where process='MRP0';
数据文件头的最小的 checkpoint_change# 来查找需要从哪个归档日志开始恢复：
select min(fhscn),fhrba_Seq SEQUENCE from x$kcvfh group by fhrba_Seq;

2.校验归档日志
  cksum 1_262_1065253017.dbf
  可以在主库或者 Standby 上执行下面的命令来验证归档日志文件是否已经损坏：
  alter system dump logfile '/arch/1_262_1065253017.dbf' validate;

3.如果归档日志找不到或者损坏，从主库复制到备库
alter database register logfile '/arch/1_262_1065253017.dbf';

4.如果没损坏，那么看看控制文件中是否有了
  select name from v$archived_log where (thread#=1 and sequence#=263);

5.检查主库上最后的归档号
select thread#, max(sequence#) "Last Primary Seq Generated"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

  备库上的最后接收归档号
  select thread#, max(sequence#) "Last Standby Seq Received"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

  备库上的最后应用归档号
  select thread#, max(sequence#) "Last Standby Seq Applied"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and applied='YES'
group by thread# order by 1;

如果缺失归档请参考增量备份前滚备库的方法。

------------------

正式分析开始

1. 是否日志传输问题
SELECT DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2;
如果提示ora-1031，ora-1017，ora-16191，ora-12154等可能是密码文件
cd $ORACLE_HOME/dbs
cksum owapwORCL

如果文件大小是不同的，您需要在主库的一个节点上创建一个新的密码文件，并拷贝到其它节点以及 standby 主机上。

orapwd file=$ORACLE_HOME/dbs/orapw<local ORACLE_SID> password=pwd_123 entries=5

对于 11g 以及以上版本的数据库，请确保初始化参数 SEC_CASE_SENSITIVE_LOGON 同时在主库和 standby 上设置为 false
如果基于安全考虑不得不把 SEC_CASE_SENSITIVE_LOGON 设置为 true，那么在创建密码文件时务必指定 ignorecase=y 参数

orapwd file=$ORACLE_HOME/dbs/orapwORCL password=pwd_123 ignorecase=y entries=5

2. 防火墙导致归档日志不完整
ORA-00332: archived log is too small - may be incompletely archived
ORA-03135: connection lost contact when shipping redo log to standby database

3. BUG：由于 bug 6113783，负责网络上的心跳的主库 ARC 进程卡住(11.2.0.2 中被修复)
 select message, timestamp
from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp;
解决方法是kill arch进程号

5：恢复是从错误的目录里进行的
alter database recover managed standby database cancel;
alter database recover automatic from '/tmp/archive/' standby database;

 6：所有的 standby redo 日志文件都处于 active 的状态
  select group#,thread#,bytes/1024/1024 as mbytes,used,archived,status
 from v$standby_log;
确保 archive 目录上有足够的空间。
log_archive_dest_1 的定义中包含准确的 valid_for 以及 db_unique_name
standby_archive_dest 被正确指定

 7：缺损的归档日志文件应用于备库
 查询 v$archived_log 来找到哪个归档日志包含 change# 14025537844
 select thread#, sequence#, name, first_change#, next_Change#, deleted, status from v$archived_log where 14025537844 between first_change# and next_Change#;

8：归档日志不是通过 dataguard 日志传输服务传输的，而是手工拷贝
recover managed standby database cancel;
RMAN> catalog start with 'PATH_TO_ARCHIVELOGS/';
recover managed standby database disconnect;
或者直接修复
alter database recover automatic from '/tmp/archive/' standby database;

 9：归档日志被传输应用到 standby 备库前就被删除
 恢复
 可以把 rman 删除策略设置为 APPLIED ON STANDBY

 10：有新的数据文件
 参考相关文档

 11：mrp卡住
 杀掉mrp或者重启备库

  12: cancel mrp卡住
  重启备库
  shu abort
  startup mount
  recover automatic standby database;

参考：
在物理 standby 数据库上如何解决 MRP 进程卡住的问题？ (Doc ID 2331842.1)