ORA-03137: TTC 协议内部错误: [12333] [8] [0] [116] [] [] [] []

1、alert_oracle.log提示报错：
Errors in file d:\app\administrator\diag\rdbms\oracle\oracle\trace\oracle_ora_12748.trc (incident=234302):
ORA-03137: TTC 协议内部错误: [12333] [8] [0] [116] [] [] [] []
Fri May 15 10:05:26 2020
Errors in file d:\app\administrator\diag\rdbms\oracle\oracle\trace\oracle_ora_5184.trc (incident=234174):
ORA-03137: TTC 协议内部错误: [12333] [8] [0] [116] [] [] [] []
Incident details in: d:\app\administrator\diag\rdbms\oracle\oracle\incident\incdir_234174\oracle_ora_5184_i234174.trc
Fri May 15 10:05:29 2020
Trace dumping is performing id=[cdmp_20200515100529]
Fri May 15 10:05:43 2020
Errors in file d:\app\administrator\diag\rdbms\oracle\oracle\trace\oracle_ora_9608.trc (incident=234014):
ORA-03137: TTC 协议内部错误: [12333] [8] [0] [116] [] [] [] []
Incident details in: d:\app\administrator\diag\rdbms\oracle\oracle\incident\incdir_234014\oracle_ora_9608_i234014.trc
Fri May 15 10:05:46 2020
Trace dumping is performing id=[cdmp_20200515100546]

With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU : 32 - type 8664, 32 Physical Cores
Process Affinity : 0x0x0000000000000000
Memory (Avail/Total): Ph:25640M/32767M, Ph+PgF:57736M/65833M
Instance name: oracle
Redo thread mounted by this instance: 1
Oracle process number: 22
Windows thread id: 9608, image: ORACLE.EXE (SHAD)

2、打开d:\app\administrator\diag\rdbms\oracle\oracle\incident\incdir_234014\

*** 2020-05-15 10:05:43.877
*** SESSION ID:(331.27295) 2020-05-15 10:05:43.877
*** CLIENT ID:() 2020-05-15 10:05:43.877
*** SERVICE NAME:(oracle) 2020-05-15 10:05:43.877
*** MODULE NAME:(w3wp.exe) 2020-05-15 10:05:43.877
*** ACTION NAME:() 2020-05-15 10:05:43.877
Dump continued from file: d:\app\administrator\diag\rdbms\oracle\oracle\trace\oracle_ora_9608.trc
ORA-03137: TTC 协议内部错误: [12333] [8] [0] [116] [] [] [] []

========= Dump for incident 234014 (ORA 3137 [12333]) ========

*** 2020-05-15 10:05:43.881
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=4bj5g1magv5r5) -----
SELECT DISTINCT a.empcode, a.menuid, a.dpid, a.visitcount, a.lastvisittime, a.menutype, b.navlink, b.menuname FROM base_emp_menulog a INNER JOIN base_menu b ON a.menuid = b.menuid WHERE a.empcode = :EmpCode and b.subsystemid<>‘6BCD4BE27087B8A6’ and a.dpid = :Dpid ORDER BY a.LASTVISITTIME desc

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)

---

ksedst1()+129 CALL??? skdstdst() 009303DA2 000000000 000000000
000000000
ksedst()+69 CALL??? ksedst1() 000000002 000000000 006F605E0
000000000
dbkedDefDump()+4536 CALL??? ksedst() 000000287 000000000 000000000
000000000
ksedmp()+43 CALL??? dbkedDefDump() 000000003 000000002 000000000
000468E71
ksfdmp()+87 CALL??? ksedmp() 000000000 000000000 000000000
000000000
dbgexPhaseII()+1819 CALL??? ksfdmp() 000000000 000000000 000000000
000000000
问题的解决方法

Metalink上面居然没有发现症状一样的问题，关于ORA-03137的错误，问题有很多，常见的问题有JDBC、绑定变量窥视、ORACLE的BUG等，Metalink也提供了一系列的排查方法，具体如下：

2.1 绑定变量的窥视

解决方法：SQL> alter system set “_optim_peek_user_binds”=false;

弊端：关闭绑定变量的窥视，会导致当SQL语句使用绑定变量的时候，产生的执行计划可能会出现不准，在生产环境中要长期关闭该特性需要认真测试；

2.2 更新数据库最新的PSU，当通过禁用绑定变量后数据库不再报错，可以应用每个数据库最新的PSU。或者当禁用绑定变量的时候也继续报错，也可以考虑应用PSU进行测试；

以下是相关的PSU信息：
PSU 11.1.0.7.8 Patch 12419384 includes Patch:9703463.
For 11.1.0.7, Patch 9243912 can be applied on top of 11.1.0.7.8 ( no conflict).
Patch:9703463 can also be applied individually but requires PSU 11.1.0.7.6
Patch:8625762 may also be applicable to databases version 11.1.0.7
2.3 更新数据库到11.2.0.3这个版本
在ORACLE 11.2.0.3这个版本中可以解决所有的ORA-3137的错误；

2.4 联系ORACLE SUPPORT解决这个问题 经过以上操作，你都踩到这个地雷了，说明楼主平时烧香少，需要联系ORALCE的大神么出手；

【3】总结：经过验证发现运行alter system set “_optim_peek_user_binds”=false后报错就消失了；

其实很多时候我们可以规避这个问题的，因为当初在选择数据库版本的时候，当初没有什么经验直接安装了11.2.0.1这个版本，大家都知道R1版本的BUG是比较多的，R2相对来说会稳定很多，但是在选择数据库的时候，也建议不要选小版本为1的，现在我装数据库的时候一般都会选择11.2.0.3这个版本；