事件背景：早上突然有同事反饋OA登入不了，面對這種情況出於DBA的職業本能一般都需要先確定下資料庫執行是否正常，也就本能的檢視了下資料庫的狀態，顯示屬於OPEN狀態。第二步檢視下資料庫的alert日誌，檢視最近的時間點是否有報錯的資訊，經過不懈的努力終於發現了最近的時間點有個ORA-03137的錯誤；

ORACLE版本：11.0.2

平臺：linux 32位

2. 錯誤日誌

2.1 alert日誌內容

Fri Sep 27 08:11:31 2013

Errors in file /data/oracle/diag/rdbms/ekpj/ekpj/trace/ekpj_ora_31911.trc (incident=40971):

ORA-03137: TTC 協議內部錯誤: [12333] [32] [49] [51] [] [] [] []

Incident details in: /data/oracle/diag/rdbms/ekpj/ekpj/incident/incdir_40971/ekpj_ora_31911_i40971.trc

Fri Sep 27 08:11:34 2013

Trace dumping is performing id=[cdmp_20130927081134]

Fri Sep 27 08:11:35 2013

2.2 ora_31911.trc 的dump日誌

*** 2013-09-27 08:11:32.047

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=35rzrx7bb4d3t) -----

select * from ( select kmreviewma0_.fd_id as fd1_1604_, kmreviewma0_.fd_last_modified_time as fd2_1604_, kmreviewma0_.doc_subject as doc3_1604_, kmreviewma0_.fd_current_number as fd4_1604_, kmreviewma0_.fd_feedback_modify as fd5_1604_, kmreviewma0_.fd_feedback_executed as fd6_1604_, kmreviewma0_.fd_number as fd7_1604_, kmreviewma0_.doc_creator_id as doc8_1604_, kmreviewma0_.doc_create_time as doc9_1604_, kmreviewma0_.fd_department_id as fd10_1604_, kmreviewma0_.doc_publish_time as doc11_1604_, kmreviewma0_.doc_read_count as doc12_1604_, kmreviewma0_.extend_file_path as extend13_1604_, kmreviewma0_.fd_use_form. as fd16_1604_, kmreviewma0_.doc_status as doc17_1604_, kmreviewma0_.auth_att_nodownload as auth18_1604_, kmreviewma0_.auth_att_nocopy as auth19_1604_, kmreviewma0_.auth_att_noprint as auth20_1604_, kmreviewma0_.auth_reader_flag as auth21_1604_, kmreviewma0_.fd_change_reader_flag as fd22_1604_, kmreviewma0_.fd_rbp_flag as fd23_1604_, kmreviewma0_.fd_change_att as fd24_1604_, kmreviewma0_.fd_model_name as fd25_1604_, kmreviewma0_.fd_model_id as fd26_1604_, kmreviewma0_.fd_work_id as fd27_1604_, kmreviewma0_.fd_phase_id as fd28_1604_, kmreviewma0_.fd_template_id as fd29_1604_, kmreviewma0_.auth_area_id as auth30_1604_ from ekpj.km_review_main kmreviewma0_ where kmreviewma0_.fd_id in (select kmreviewma1_.fd_id from ekpj.km_review_main kmreviewma1_, ekpj.km_review_main_areader authallrea2_, ekpj.sys_org_element sysorgelem3_ where kmreviewma1_.fd_id=authallrea2_.fd_doc_id and authallrea2_.auth_all_reader_id=sysorgelem3_.fd_id and 1=1 and kmreviewma1_.doc_creator_id=:1 and (sysorgelem3_.fd_id in (:2 , :3 , :4 , :5 , :6 , :7 , :8 , :9 , :10))) order by kmreviewma0_.doc_create_time desc, kmreviewma0_.fd_id desc ) where rownum <= :11

這個問題從來沒有遇到過，那可怎麼辦？

方法很簡單，先上網查詢。

功夫不負有心人，很快就從網上找到了原因，具體說明如下：

該錯誤和網路上說是屬於ORACLE的一個bug；

目前資料庫最新版本是11.2.0.1.3
在11.2下同樣也會出現ORA-03137,解決辦法是：
在11.2.0.1.0下打patch9243912加設定_optim_peek_user_binds=false(設定這個引數可能影響CBO執行計劃)

根據網上兄弟提供的解決方法，摘錄如下：

4.1可以透過更換不同版本的JDBC驅動來避免該錯誤，也說明為什麼同事在另外一套環境下，透過Weblogic的JDBC來訪問資料庫時，則不會遇到該錯誤；

4.2 給資料庫打patch,初步認為可以透過打 來解決；

4.3透過修改資料庫引數來規避該錯誤：

修改之後，同事用之前的Tomcat那個版本的驅動來重新訪問資料庫時，則不再報錯；

4.3直接升級資料庫版本至11.2.0.3.0，透過匯出匯入的方式將剛專案組下的schema資料複製一份到一套11.2.0.3.0的庫上，重新使用Tomcat那個版本的驅動來重新訪問資料庫時，亦不再報錯。

雖然網上提供提供了多個解決方法，但是最終的解決方法還是需要根據各自的系統情況來進行選擇，出現了問題得自己負責。

經過抉擇先把這個引數_optim_peek_user_binds=false，主要考慮如下：第一該方法簡單，簡單就是王道；第二，該操作可逆，如果不是這個問題那麼可以再把引數修改回來；

_optim_peek_user_binds=false屬於隱藏引數，可以透過以下語句進行查詢

SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description

2 from x$ksppi a,x$ksppcv b

3 where a.inst_id = USERENV ('Instance')

4 and b.inst_id = USERENV ('Instance')

5 and a.indx = b.indx

6 and upper(a.ksppinm) LIKE upper('%&param%')

7 order by name

8 /

Enter value for param: _optim_peek_user_binds

old 6: and upper(a.ksppinm) LIKE upper('%&param%')

new 6: and upper(a.ksppinm) LIKE upper('%_optim_peek_user_binds%')

NAME VALUE DESCRIPTION

-------------------------------- ------------------------ ----------------------------------

_optim_peek_user_binds TRUE enable peeking of user binds