记一则玄乎奇玄的ADG误删自救事件
架构：Oracle11g+adg
os：AIX5.3
周日加班，开发人员对生产用户、生产数据库一顿操作，导致归档爆满，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备库。
