记一则玄乎奇玄的ADG误删自救事件
作者:互联网
架构: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