DATAGARUD主庫報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


備庫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，問題解決！