今天在DataGuard环境里，遇到Logical standby的APPLY节点报ORA-16146的错。

硬件环境就不描述了，主要场景如下:

OS版本：AIX平台

ORACLE版本：10.2.0.3

Data guard :

Primary是3节点的RAC

Logstdby的APPLY节点相当于2个primary节点的配置

测试场景：

Primary实施大压力测试(CPU资源使用率超过70%)

Primary上的redolog生成速度超过15M/s

Logical Standby上的public网络流量超过50M/s

Logical standby上存放归档的的hdisk-busy基本维持在100%左右

问题描述：

Standby与Primary之间的产生大量的GAP，且越来越多

查看standby的APPLY节点alert日志，报"ORA-16146: standby destination control file enqueue unavailable"

问题解决：
暂停Primary database上的模拟压力，Standby节点上的GAP日志数慢慢减少，不再报错。注：由于是测试环境，所以可以随时停掉模拟业务。但是生产系统肯定不能这样，到底是什么原因引起的，该怎样避免呢？

问题分析：
出现问题时，系统的场景主要就是Primary database正在实施大压力logical standby要APPLY来自Primary所有节点的SQL，APPLY节点redolog的生成速度超过17M/s。

通过进一步翻看查找standby节点的alert日志发现，在系统报"ORA-16146"的错误日前，系统日志里有以下日常记录：

"Thread 2 advanced to log sequence 1027

Current log# 6 seq# 1027 mem# 0: +DATAGRP1/zc/onlinelog/group_6.469.653686929

Thu May 8 16:25:04 2008

ORACLE Instance zc2 - Can not allocate log, archival required

Thu May 8 16:25:04 2008

Thread 2 cannot allocate new log, sequence 1028

All online logs needed archiving"

可以判断，引起数据库报"ORA-16146"的错是由STANDBY节点不能进行正常的归档造成的。但Standby节点为什么不能正常归档呢，怀疑是因为Standby节点的压力过大,redolog的切换频率过快，日志组的online redo log还没archived，已经再次循环到current状态，导致数据库异常。注：报错时，查看系统资源存放归档日志的hdisk确实比较忙，busy达到100%，磁盘IO存在瓶颈。

最后，竟然在metalink上发现这又是ORACLE的一个BUG，BUG号为"6004936"，嗯，解决办法就是升级到10.2.0.4或是11g，没完没了啦！

总结一下：

基本上，上述问题是在系统资源特别是网络和IO出现瓶颈的时候会出现，当然这个时候生产系统已经不堪重负了。预防措施就是：

1.提升系统比较忙的hdisk的IO性能2.增加数据库的onling redolog 的日志组成员数3.升级数据库的版本，很有可能引发新问题的