Dataguard主库报ORA-16146错误解决

产品版本 10.2.0.4
操作系统 Oracle Solaris on SPARC （64-bit） 5.10一、alert日志如下：
主库alert log
---------------------
Tue Mar 11 14:30:47 2014
LNS: Standby redo logfile selected for thread 2 sequence 192246 for destination LOG_ARCHIVE_DEST_2
Tue Mar 11 14:37:00 2014
Errors in file /oracle/admin/dbrac/bdump/dbrac2_arc9_6512.trc:
ORA-16146: standby destination control file enqueue unavailable
Tue Mar 11 14:37:00 2014
Master background archival failure: 16146
Tue Mar 11 14:40:07 2014
Errors in file /oracle/admin/dbrac/bdump/dbrac2_arc9_6512.trc:
ORA-16146: standby destination control file enqueue unavailable
--------------------------------------分割线 -------------------------------------- 相关参考:Oracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htmOracle Data Guard （RAC+DG）归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htmOracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htmOracle Data Guard的日志FAL gap问题 http://www.linuxidc.com/Linux/2013-04/82561.htmOracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm--------------------------------------分割线 --------------------------------------备库alert log
---------------------
Tue Mar 11 14:29:44 2014
Primary database is in MAXIMUM PERFORMANCE mode
RFS[19]: Successfully opened standby log 8: "+DATA/dbrac_standby/onlinelog/group_8.473.823623967"
Tue Mar 11 14:32:12 2014
Primary database is in MAXIMUM PERFORMANCE mode
RFS[13]: Successfully opened standby log 12: "+DATA/dbrac_standby/onlinelog/group_12.1879.823705847"
Tue Mar 11 14:34:26 2014
Media Recovery Log +DATA/dbrac_standby/archivelog/2014_03_11/thread_2_seq_192246.509.841933921
Tue Mar 11 14:34:48 2014
Media Recovery Log +DATA/dbrac_standby/archivelog/2014_03_11/thread_1_seq_193463.1784.841933765
Tue Mar 11 14:35:44 2014
Primary database is in MAXIMUM PERFORMANCE mode
RFS[19]: Successfully opened standby log 7: "+DATA/dbrac_standby/onlinelog/group_7.492.823623957"
Tue Mar 11 14:37:37 2014
Media Recovery Waiting for thread 1 sequence 193464 （in transit）
Tue Mar 11 14:38:47 2014
Media Recovery Log +DATA/dbrac_standby/archivelog/2014_03_11/thread_1_seq_193464.2163.841934073
Tue Mar 11 14:40:01 2014
Media Recovery Waiting for thread 2 sequence 192247 （in transit）
二、分析及处理
分析思路：
ORA-16146错误说明有进程持有CF enqueue（控制文件锁）超过900秒没有释放，导致其他进程无法获得CF enqueue，
其实这个错误信息有些不够准确，不单单是等待备库的CF enqueue，等待主库的CF enqueue时也会报这个错误。

导致ORA-16146错误的原因可能有：
1. IO性能慢，导致IO操作时间过长。
2. 某个持有CF enqueue（控制文件锁）超过900秒没有释放。
3. 控制文件中的信息过多，导致查询控制文件时间过长。
4. 如果只是单纯出现ORA-16146，而没有其他问题，那么这个错误是可以忽略的。

进一步检查：
1. OSW 或者其他OS资源监控数据
2. 主库和备库分别查询：
SQL>select count（*） from v$archived_log;
SQL>select count（*） from v$log_history;
SQL> select count（*） from v$archived_log;
SQL> select count（*） from v$log_history;
SQL> show parameter CONTROL_FILE_RECORD_KEEP_TIME;
查询如下：
主库备库
select count（*） from v$archived_log; 18956 18956
select count（*） from v$log_history; 36272 36272
select count（*） from v$archived_log; 18956 18956
select count（*） from v$log_history; 36272 36272
show parameter CONTROL_FILE_RECORD_KEEP_TIME; 7 10
3. Sun: /var/adm/messages（主库和备库）

分析解决
通过查询试图 v$archived_log 和 v$log_history，发现大量历史日志信息，因此很有可能是由于控制文件中记录的日志数量是非常多的，
查询时会消耗比较多的时间。
修改参数如下：
alter system set CONTROL_FILE_RECORD_KEEP_TIME=3 scope=BOTH;
通过几个星期的观察，没再出现ORA-16146，问题解决！更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址