产品版本 10.2.0.4操作系统 oracle solaris on sparc (64-bit) 5.10 一、alert日志如下： 主库alert log ---------------------
产品版本 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 重要配置参数
基于同一主机配置 oracle 11g data guard
探索oracle之11g dataguard
oracle data guard （rac+dg) 归档删除策略及脚本
oracle data guard 的角色转换
oracle data guard的日志fal gap问题
oracle 11g data guard error 16143 heartbeat failed to connect to standby 处理方法
--------------------------------------分割线 --------------------------------------
备库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，问题解决！
本文永久更新链接地址：