mrp的各种问题及处理 redo不应用 dg延时 等-凯发app官方网站

凯发app官方网站-凯发k8官网下载客户端中心 | | 凯发app官方网站-凯发k8官网下载客户端中心
  • 博客访问: 3502952
  • 博文数量: 718
  • 博客积分: 1860
  • 博客等级: 上尉
  • 技术积分: 7790
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-07 08:51
个人简介

偶尔有空上来看看

文章分类

全部博文(718)

文章存档

2024年(4)

2023年(74)

2022年(134)

2021年(238)

2020年(115)

2019年(11)

2018年(9)

2017年(9)

2016年(17)

2015年(7)

2014年(4)

2013年(1)

2012年(11)

2011年(27)

2010年(35)

2009年(11)

2008年(11)

最近访客
相关博文
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·

分类: oracle

2021-08-19 22:15:31


  1. 物理 standby 数据库应用的日志 sequence# 不再增加,或者 mrp 卡住不再应用任何日志,改如何分析?

  2. 先做个初步处理

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

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

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

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

  15. 5.检查主库上最后的归档号 
  16. select thread#, max(sequence#) "last primary seq generated"
  17. from v$archived_log val, v$database vdb
  18. where val.resetlogs_change# = vdb.resetlogs_change#
  19. group by thread# order by 1;

  20.   备库上的最后接收归档号
  21.   select thread#, max(sequence#) "last standby seq received"
  22. from v$archived_log val, v$database vdb
  23. where val.resetlogs_change# = vdb.resetlogs_change#
  24. group by thread# order by 1;

  25.   备库上的最后应用归档号
  26.   select thread#, max(sequence#) "last standby seq applied"
  27. from v$archived_log val, v$database vdb
  28. where val.resetlogs_change# = vdb.resetlogs_change#
  29. and applied='yes'
  30. group by thread# order by 1;

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

  32. ------------------

  33. 正式分析开始

  34. 1. 是否日志传输问题
  35. select destination, status, error from v$archive_dest where dest_id=2;
  36. 如果提示ora-1031,ora-1017,ora-16191,ora-12154等可能是密码文件
  37. cd $oracle_home/dbs
  38. cksum owapworcl

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

  40. orapwd file=$oracle_home/dbs/orapw<local oracle_sid> password=pwd_123 entries=5

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

  43. orapwd file=$oracle_home/dbs/orapworcl password=pwd_123 ignorecase=y entries=5

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

  47. 3. bug:由于 bug 6113783,负责网络上的心跳的主库 arc 进程卡住(11.2.0.2 中被修复)
  48.  select message, timestamp
  49. from v$dataguard_status
  50. where severity in ('error','fatal')
  51. order by timestamp;
  52. 解决方法是kill arch进程号

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

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

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

  65. 8:归档日志不是通过 dataguard 日志传输服务传输的,而是手工拷贝
  66. recover managed standby database cancel;
  67. rman> catalog start with 'path_to_archivelogs/';
  68. recover managed standby database disconnect;
  69. 或者直接修复
  70. alter database recover automatic from '/tmp/archive/' standby database;

  71.  9:归档日志被传输应用到 standby 备库前就被删除
  72.  恢复
  73.  可以把 rman 删除策略设置为 applied on standby

  74.  10:有新的数据文件
  75.  参考相关文档

  76.  11:mrp卡住
  77.  杀掉mrp或者重启备库

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

参考:
在物理 standby 数据库上如何解决 mrp 进程卡住的问题? (doc id 2331842.1)
阅读(8072) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
")); function link(t){ var href= $(t).attr('href'); href ="?url=" encodeuricomponent(location.href); $(t).attr('href',href); //setcookie("returnouturl", location.href, 60, "/"); }
网站地图