求助:ORA-03137: TTC 协议内部错误: [1010] [] [] [] [] [] [] []

foxhuntwang

数据库版本:11.2.0.4.0
操作系统 : aix 6.1
非 RAC

应用日志突然爆出 再执行一个UPATE 语句的时候 报  ORA-01010 无效的 OCI 操作 详细建见图片.

根据日志时间点查看了 alert.log ,相同时间点 ALERT 日志里面 有如下内容:

Tue Dec 20 11:41:59 2016
Errors in file /oracle/diag/rdbms/mccm/mccm/trace/mccm_ora_32571460.trc  (incident=231577):
ORA-03137: TTC  : [1010] [] [] [] [] [] [] []
Incident details in: /oracle/diag/rdbms/mccm/mccm/incident/incdir_231577/mccm_ora_32571460_i231577.trc
Tue Dec 20 11:42:07 2016
Dumping diagnostic data in directory=[cdmp_20161220114207], requested by (instance=1, osid=32571460), summary=[incident=231577].

附 trc 文件


mccm_ora_32571460.zip (7.53 KB, 下载次数: 1051)

2016-12-23 14:01 上传

点击文件名下载附件

mccm_ora_32571460_i231577.zip (887.4 KB, 下载次数: 785)

2016-12-23 14:01 上传

点击文件名下载附件

Liu Maclean(刘相兵

算常见问题， jdbc什么版本。 该问题的 trouble shooting master note仔细看过了吗？

foxhuntwang

就找到一个类似的描述,但是故障发生的条件和我们的不同:
Bug 16444583 - ORA-3137 [1010] from FGA on HS (文档 ID 16444583.8)

foxhuntwang

找到一点信息:
SQLException for SQL []; SQL state [72000];
error code [1010]; ORA-1010: invalid OCI operation

even though this is thin.

Hunting for the error with opiierr finds numerous reports vs 11g. Bug
6741577 says the ORA-3137 with [1010] happens when oracle can’t consume all
the bytes received on the wire. This sounds to me like more data is being
sent than expected. In that bug it suggested adding:

event=”1010 trace name errorstack level 2″

to the init.ora to try and get a trace from the 1010.

Note 35928.1 says 12333 followed by 3 parameters means a request is being
received from a network packet and the request code in the packet is not
recognized. The three additional values report the invalid request values
received.

Both these issues seem to indicate some sort of corruption in the data being
sent to the d/b, possibly because JDBC is sending bad info or there is a
problem on the network itself. We ideally need to see a corresponding client
and server side net trace in order to determine where the problem is
occurring.
There is a similar 11g bug, bug 7238542. In that bug they believe the
problem may occur when the cursor is reloaded into the shared pool. A
protocol violation occurs on the server but is not signalled to the client so
the next request from the client also causes a violation which results in the
server side aborting. Bug 7446725 was raised from this and is currently
assigned to SE as the conclusion was a diagnostics patch would probably be
required to resolve this.

If the same is happening here then a workaround may be to pin the failing
selects in the shared pool.