标签：主库 备库 文件系统 误删 ADG 奇玄 归档 日志 password
架构：Oracle11g+adg
os：AIX6.1
周日加班，开发人员对生产用户、生产数据库一顿操作，导致归档爆满，adg备库文件系统显示磁盘不足，无法继续写入，当即选择手动删除归档日志（RMAN已经不能进入了）。进入到目标目录，首先我找到了三天前的归档，手动直接删了，然后此时已经能进入rman工具了，于是进入rman命令行执行删除归档，仅保留当天的，因为当天执行sql特别多使得产生了特别多的归档日志，dg备库的文件系统剩余一直减少，所以就想再把当天的归档删除一部分，不知道是因为喝咖啡心慌手抖还是周六晚上也加班了犯困 。于是 执行命令，rm -rf 1_4609*(1_46090—1_46099)。 当时最高的日志已经到了1_47099了。执行完之后，alert报错
*********************************************************************************************
Media Recovery Log /u01/arch/1_46099_980797633.dbf
Error opening /u01/arch/1_46099_980797633.dbf
Attempting refetch
Media Recovery Waiting for thread 1 sequence 46099
Fetching gap sequence in thread 1, gap sequence 46099-46099
Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
------------------------------------------------------------
FAL[client, USER]: Error 16191 connecting to cpzb20181 for fetching gap sequence
Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
********************************************************************************************************
通过查询才知道，dg备库因为机器差，性能低，sql执行的缓慢，再加上文件系统爆满日志不能继续写，所以在我第二次手动删除归档日志的时候此时备库正在执行46090。
oracle找不到46090日志了，就一直在报错。
处理方法：主库的归档是没动的，可以把主库的归档日志手动拷贝到备库，备库就会自动执行，恢复正常。
所以忙着从主库asm里往备库文件系统拷贝归档日志文件
先从asm中cp到主库文件系统，然后从主库文件系统scp到备库，然后发现aix系统没有预装ssh命令，然后要用ftp命令，然后rcp，
然后在我纠结怎么拷过去的时候，玄乎奇玄的事情发生了。
ADG备库日志应用到46100文件了，然后查询V$archived_log视图发现4609*的十个日志显示applied为NO，就意味着备库没有应用这十个日志，很大概率上就会出现问题。然后备库还在很努力的一直追赶着最新的archive文件，经过漫长的等待，主库的复杂操作结束，备库追赶上了主库，此时，我对比了主库备库的所有表的行数，完全一致的。最困扰程序员最大的问题不是怎么会报错呢，而是怎么会运行成功呢。抱着很大的疑惑以及貌似没有问题了的状态就下班了。
第二天，发现v$archived_log视图里的46090-46099这十个序号分别对应两个文件，都是一个应用了，一个没有应用，这就解释了为什么备库能继续执行46100后的日志文件。
此时此刻只想说一句：oracle属实牛逼~~~
****************************************************************************************************************************************
总结一下
****************************************************************************************************************************************
ADG归档爆满的处理方式
1、能进rman一定要进入rman删除过期失效归档。
2、不能进入rman需要手动删除归档，删除归档时一定要查一下备库应用到那个地方了，如果此时已经不能查询了，尽量删一天以前的归档。
3、误删之后，要保证主库正常（运行正常以及日志完整）。
4、将主库的日志再次传递到备库是可以拯救备库的。
5、即使adg备库拯救不了了，只要保证主库rac正常就可以再次搭建dg备库。
标签：主库,备库,文件系统,误删,ADG,奇玄,归档,日志,password 来源： https://www.cnblogs.com/Wardenking/p/13467849.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。