怎么解决DataGuard环境中主库RMAN删除归档时报ORA-08137问题

本篇内容主要讲解“怎么解决DataGuard环境中主库RMAN删除归档时报ORA-08137问题”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么解决DataGuard环境中主库RMAN删除归档时报ORA-08137问题”吧!客户环境：2节点rac，Centos6.5，配置了一个单实例physical standby，数据库数据量200g左右，日归档量10g问题现象：2019年11月20日，源端备份软件每天全备数据库，RMAN删除三天前归档，但是监控系统报空间不足，经过检查，归档依然保留了2019年11月12日的到2019年11月20日的归档，并没有删除三天前的归档，经过检查备份软件生成备份日志，发现日志中报错如下：（1）分析原因通过报错描述，初步判断为两方面原因：a.有进程打开持有归档b.归档日志并未传输应用到physical standby端，由于配置了physical standby，默认如果归档日志未在备库应用，源库不允许使用RMAN删除归档，防止发生ga免费主机域名p。（2）排查a.排查是否有进程持有打开未删除归档11g版本中asmcmd控制台中可以使用lsof命令查看asm磁盘中文件打开情况：通过检查，发现有进程打开了2019年11月13日归档，通过了解，此库并未配置OGG、SharePlex等复制软件，仅有DataGuard，且DG备库在合肥，网络丢包较为严重，此时判断打开的13日归档为DG传输进程，我们去数据库中通过如下查询语句印证了该判断。但是同时，通过执行如下命令发现，隔段时间可以删除一部分归档，但是报错的归档序号并没有进程打开使用，所以排除有进程持有打开导致ORA-08137可能性。b.排查是否由于归档未被DataGuard应用导致无法删除通过如下命令检查physical standby端进程状态：发现RFS接收进程正在接受的归档确实为11月13日无法删除的归档sequence#。通过如下命令检查primary端归档应用情况：发现physical standby端仅仅应用到了11月13日的日志，比当前足足落后了7天，所以基本判断网络丢包严重导致发送接收缓慢，导致无法归档无法及时被physical端接收应用导致无法删除。通过与客户了解，客户基本放弃了使用该physical standby，所以我们可以使用如下几种解决办法：（1）选择合适时机，清除DG环境a.将primary置为最大性能模式b.重置Data Guard初始化参数c.删除Standby Redologsd.如果需要，可以将physical standby转换为独立的数据库使用（2）临时解决该问题，可以通过设置参数log_archive_dest_state_2为defer以及隐含参数_deferred_log_dest_is_valid为false来消除删除报ORA-08137问题_deferred_log_dest_is_valid参数默认为TRUE，控制log_archive_dest_state_n参数设置为defer时，是否允许primary归档在未被physical standby应用时删除，防止再次将log_archive_dest_state_n设置为enable时，gap发生，导致physical standby不可用，该参数在11.2.0.4版本中为可动态调整参数，可以在线修改。（3）删除归档使用force选项到此，相信大家对“怎么解决DataGuard环免费主机域名境中主库RMAN删除归档时报ORA-08137问题”有了更深的了解，不妨来实际操作一番吧！这里是云技术网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！

相关推荐: 怎么随系统systemctl启动数据库

本篇内容主要讲解“怎么随系统systemctl启动数据库”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么随系统systemctl启动数据库”吧!到此，相信大家对“怎么随系统systemctl启动数据库”有了更深的…