个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2021-08-19 22:15:31
-
物理 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;
重启备库
shu abort
startup mount
recover automatic standby database;
在物理 standby 数据库上如何解决 mrp 进程卡住的问题？ (doc id 2331842.1)
给主人留下些什么吧！~~