bug说：
The solution is to upgrade the database to version 11.1.0.7 where the problem is fixed.
Note: Although upgrading to database version 11.1.0.7 has been confirmed to have solved this issue in a high number of cases, error ORA-3137 [12333] accompanied by Protocol Violation messages may still occur intermittently in database versions prior to 11.2, including database 10.2.0.4 and 11.1.0.7.
This has been reported in unpublished bug:8625762 ORA-3137 [12333] due to bind data not read from wire, in which case ORA-3137 [12333] can occur intermittently for SQL which uses user binds due to bind data being left unread on the Net connection. The bug suggests the workaround of setting "_optim_peek_user_binds"=false to avoid this problem (workaround to be used with caution as it can affect execution plans chosen by CBO), and also provides the fix by the application of Patch:8625762.
请参考 mos上的 752297.1!这是11.1.0.6上的一个bug：ID 7390077，metalink文档ID 752297.1描述了这个，利用11.1.0.6的JDBC瘦客户端驱动访问11.1.0.6数据库可能导致这个错误。
解决这个问题需要将数据库版本升级到11.1.0.7，但是Oracle也提到，即使升级到11.1.0.7也不能完全避免这个错误，除非升级到11.2以上的版本，否则在错误日志中仍然可以偶尔发现这个错误信息。
驱动问题说：
Oracle Solaris上的一套11.2.0.1.0最近出现以下告警记录:
Dump file /cnbbs01/app/oracle/diag/rdbms/nbbsprd1/nbbsprd1/incident/incdir_373041/nbbsprd1_ora_24754_i373041.trc Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production ORACLE_HOME = /cnbbs01/app/oracle/product/11.2.0/db_1 System name: SunOS Node name: ut06db03 Release: 5.10 Version: Generic_142901-12 Machine: i86pc Instance name: nbbsprd1 Redo thread mounted by this instance: 1 Oracle process number: 130 Unix process pid: 24754, image: oracle@ut06db03 *** 2010-08-25 02:01:19.169 *** SESSION ID:(1203.16390) 2010-08-25 02:01:19.169 *** CLIENT ID:() 2010-08-25 02:01:19.169 *** SERVICE NAME:(SYS$USERS) 2010-08-25 02:01:19.169 *** MODULE NAME:() 2010-08-25 02:01:19.169 *** ACTION NAME:() 2010-08-25 02:01:19.169 Dump continued from file: /cnbbs01/app/oracle/diag/rdbms/nbbsprd1/nbbsprd1/trace/nbbsprd1_ora_24754.trc ORA-03137: TTC protocol internal error : [12333] [11] [120] [110] [] [] [] []
========= Dump for incident 373041 (ORA 3137 [12333]) ========
*** 2010-08-25 02:01:19.170
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=8ath6p5cx60q2) -----
SELECT eventtime, messageid, result, userid, username, userdomainid, objid, objname, objdomainid, data, data0, obj2id, server FROM eventlog a WHERE 1 = 1 AND EVENTTIME < :1 AND EVENTTIME > :2 AND messageid IN ('AdminUIAudit' , 'NBIAudit') ORDER BY EVENTTIME DESC
----- Call Stack Trace -----
ksedst1 <- ksedst <- dbkedDefDump <- ksedmp <- dbgexPhaseII
<- dbgexProcessError <- dbgePostErrorKGE <- 1438 <- opiierr <- opitsk
<- opiino <- opiodr <- opidrv <- sou2o <- opimai_real
<- ssthrdmain <- main <- start
----------------------------------------
SO: 0x5fb961a98, type: 4, owner: 0x5fff8fd60, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0x5fff8fd60, name=session, file=ksu.h LINE:11467 ID:, pg=0
(session) sid: 1203 ser: 16390 trans: 0x0, creator: 0x5fff8fd60
flags: (0x41) USR/- flags_idl: (0x0) -/-/-/-/-/-
flags2: (0x40008) -/-
DID: , short-term DID:
txn branch: 0x0
oct: 3, prv: 0, sql: 0x5b08829c0, psql: 0x5d799a460, user: 67/NBBS_MTS
ksuxds FALSE at location: 0
service name: SYS$USERS
client details:
O/S info: user: , term: , ospid: 1234
machine: ut06nbbs01 program:
Current Wait Stack:
Not in wait; last wait ended 1.274194 sec ago
以上Select语句在sqlplus或sql developer等工具远程登录后执行均没有出错，仅在使用jdbc驱动连接时出现ORA-03137: TTC protocol internal error : [12333] [11]错误；提交SR，MOS认为该应用使用的JDBC API version 2.1过旧，建议升级到最新版本。
这个case通过升级jdbc驱动解决了。
© 2010, . 版权所有.
wrote:
ora-600 [12333] / ora-3137 [12333] Troubleshooting
Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.1.0.7 – Release: 10.2 to 11.1
Information in this document applies to any platform.
Symptoms
ora-600 [12333] / ora-3137 [12333]
Cause
This could happens if a statement take a time and the process could have a timeout and died , this errors means that the process died or was killed
Solution
The ora-600 [12333] error is only telling us that the client and server process communication was terminated due to some event.
This error is only affecting the session seeing the error and not the instance as a whole.
For any ONE-TIME occurrence we can safely ignore the error.
This error does not relate to any potential data corruption or any data loss.
If it would come back and re-occur over and over, would indicate a problem, but isolated incident is not a concern.
Please first check for any incompatibility between database version and clients, see :
- Client / Server / Interoperability Support Between Different Oracle Versions
Then we will need to to check if we are doing any remote processing to monitor the process and the network traffic.
We should look for which session/program/application that triggers this issue.
This shall be found from the trace files under the session state object ‘(session)’.
Sometimes the ORA-00600 [12333] trace files will not capture the session information, in such cases we can Check with the end users about any issues around the time-frame of this internal error.
There is a HIGH chance for application run-time exception to lead to this ORA-00600 [12333].
Due to the unhandled exceptions there is a chance for incomplete information passed to the server, hence the internal errors are raised. In such cases, handling those exceptions (or) addressing those errors on the application code will resolve the issue.
In few cases, the problem application will work for a while before it terminates with the error.
This could be due to the TIMEOUT settings at the Application Server (or) Forms Server.,etc.
To resolve this either tune the failing application to complete within the TIMEOUT value (or) reset the TIMEOUT to an optimal value.
There could be more possibilities here; in simple words the approach should be from application side, which would help us to understand the other issues that, triggered this network interruption.
In-case if all the above suggestions does not help to identify the cause, and the ORA-00600 [12333] persists we may need to enable the networking tracings from the problem client and need to review the network traces to understand where the problem occurs. See:
– SQL*Net, Net8, Oracle Net Services – Tracing and Logging at a Glance
Check also the following note for more info on already reported issues :
– ORA-600 [12333] "Fatal Two-Task Protocol Violation"
In case, you notice JDBC Client as the failing program under Session state object, please check and ensure that you use latest compatible version of JDBC Drivers in your application side.
You can refer to :
To verify the version of JDBC Drivers and for Installation steps
In case jdbc is used, then a good procedure to prevent this kind of behavior is to control the following things from the jdbc application side :
- Check that you are using the last jdbc driver
- Monitor and try to handle correctly the timeouts from the application
- Check that idle or died programs/processes are not just killed at the client side but using a good cleaning procedure.
- Increase queue sizes / buffers and similar from the jdbc side.
An ORA-600[12333] is reported with three additional numeric values when a request is being received from a network packet and the request code in the packet is not recognized.
Once the execution of the sql is completed, if there is any data (which is sent by the client) left on the wire which was intended to be consumed by the server during the execution of this sql ,this error occurs.
For example, Let us say if the application is doing an array DML operation and executing the following statement "Insert into test_table ( :1 , :2)" .
Application would have provided bind information for all the iterations. Because of some error during one of the iterations or due to some code bug if server failes to read all the bind data by the end of all the iterations this tracing will come into play and print the information "PROTOCOLVIOLATION DETECTED"
Normally if application continues after this we would see an ORA-600[12333] error or an ORA-3106 error or some unexpected behavior.
It is just an indication of above such conditions.
Finally, have the network team to investigate the network for any problems. If the error is intermittent and not reproducible at will, this could indicates the problem may not be in the database, but in the environment. ORA-600 [12333] is a client communication problem involving the network and can also be caused by dropped packets.
| September 5th, 2010 at pm 8:52
wrote:
ORA-600 [12333] “Fatal Two-Task Protocol Violation”
PURPOSE:
This article discusses the internal error “ORA-600 [12333]“, what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.
ERROR:
ORA-600 [12333] [a] [b] [c] [d]
VERSIONS:
Versions 6.0 to 10.2
DESCRIPTION:
There are three forms of the OERI(12333) error:
i. Usage with 4 additional values: ORA-600 [PTI] [b] [c] [d]
Reported by Oracle release 8.0 onwards
ii. Usage with 4 additional values: ORA-600 [a] [b] [c] [d]
Reported by Oracle release 8.0 onwards
iii. Usage with 3 additional values: ORA-600 [a] [b] [c]
Reported by Oracle release 7 and earlier.
The first form of the error is “ORA-600 [12333] [PTI] [b] [c] [d]”
This may be reported when parsing storage options on alter/create of
various database objects. The [b], [c], [d] arguments identify a
specific statement type being parsed.
This form of the error indicates a problem in the sql parser. As common
functions are used to parse the storage options of different database
objects, this error code is used as a semantic check that the parser has
not passed options that are invalid for the statement being parsed.
The second form of the error is “ORA-600 [12333] [a] [b] [c] [d]”
This represents a Two Task Protocol violation and is reported because
an OCI call has been sent in the wrong order.
The third form of the error is “ORA-600 [12333] [a] [b] [c]”
The ORA-600 [12333] is reported with three additional numeric values
when 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.
The error may have a number of different root causes. For example, a
multi-threaded Client-side application sent an OCI call out of order, or the
data in the network buffer may have been overwritten.
Since there are many potential causes of this error, it is essential to
have a reproducible testcase to correctly diagnose the underlying cause.
ARGUMENTS:
Form i.
Arg [a] PTI
Arg [b] Parse process Options
Arg [c] Statement type
Arg [d] Check identification, e.g., INDEX
Form ii.
Arg [a] TTI message
Arg [b] OPI function code
Arg [c] Sequence number
Arg [d] typically 0
Form iii.
Arg [a] TTI Layer Function code received
Arg [b] Function code
Arg [c] Sequence
FUNCTIONALITY:
USER/ORACLE INTERFACE LAYER
IMPACT:
PROCESS FAILURE
NO DATA CORRUPTION
SUGGESTIONS:
Update to the latest Client or Database patch set.
Check the Known Issues section below for your version.
Check networking connections and NLS settings: Note:77442.1.
| September 5th, 2010 at pm 8:59
admin wrote:
ORA-03137: TTC Protocol Internal Error : [12333] Using JDBC Driver
Applies to:
JDBC – Version: 11.1.0.6 and later [Release: 11.1 and later ]
Information in this document applies to any platform.
Symptoms
On 11.1.0.6 in Production, when attempting to run an application using the JDBC thin driver 11.1.0.6 against a database version 11.1.0.6, the following error occurs:
ORA-03137: TTC protocol internal error : [12333] [10] [83] [74] [] [] [] []
The stack trace in the database alert log is:
—– Current SQL Statement for this session (sql_id=c0czhbm4hcz98) —–
DELETE FROM PORTAL_CONCURRENT_USER_SCRATCH
WHERE LAST_LOGIN < :intervalStartDate
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————– —————————-
skdstdst()+002c bl 105e2771c
ksedst1()+0064 bl 101fad134
ksedst()+0028 bl ksedst1() 60000B8104C4A30 ?
600000002050032 ?
dbkedDefDump()+07fc bl 101fae954
ksedmp()+0048 bl 101fad130
opiierr()+0168 bl ksedmp() 000000000 ?
opitsk()+1344 bl 103ec9a5c
opiino()+09a0 bl opitsk() 110098B40 ? 000000000 ?
opiodr()+0b48 bl 103ec7a30
opidrv()+0440 bl opiodr() 3C61672F72 ? 41032E668 ?
FFFFFFFFFFFF7E0 ? 073702F74 ?
sou2o()+0090 bl opidrv() 3C05C04AEC ? 4A09A9924 ?
FFFFFFFFFFFF7E0 ?
opimai_real()+01b0 bl 101face8c
main()+0090 bl opimai_real() 000000000 ? 000000000 ?
__start()+0098 bl main() 000000000 ? 000000000 ?
This problem does not happen if the 10.2.0.3 driver is used.
Cause
According to ORA-3137: TTC PROTO INTERNAL ERROR: [12333] [8] [80] [65] reported for JDBC 11.0.6.0, this bug is an RDBMS bug and not JDBC.
Solution
The solution is to upgrade the database to version 11.1.0.7 where the problem is fixed.
Note: Although upgrading to database version 11.1.0.7 has been confirmed to have solved this issue in a high number of cases, error ORA-3137 [12333] accompanied by Protocol Violation messages may still occur intermittently in database versions prior to 11.2, including database 10.2.0.4 and 11.1.0.7.
This has been reported in unpublished bug:8625762 ORA-3137 [12333] due to bind data not read from wire, in which case ORA-3137 [12333] can occur intermittently for SQL which uses user binds due to bind data being left unread on the Net connection. The bug suggests the workaround of setting “_optim_peek_user_binds”=false to avoid this problem (workaround to be used with caution as it can affect execution plans chosen by CBO), and also provides the fix by the application of .
References
– ORA-03137: TTC PROTO INTERNAL ERROR : [12333] [21] [106] [110] [] [] [] []
– Bug 8625762 – ORA-3137 [12333] due to bind data not read from wire
| September 5th, 2010 at pm 9:05
admin wrote:
Hdr: 7445550 11.1.0.6.0 RDBMS 11.1.0.6.0 PRG INTERFACE PRODID-5 PORTID-226 ORA-3137 7390077
Abstract: ORA-3137: TTC PROTO INTERNAL ERROR : [12333] [21] [106] [110] [] [] [] []
PROBLEM:
Customer is in database 11.1.0.6 and JDBC Thin driver 11.1.0.6 and is getting
error :
ORA-3137: TTC proto internal error : [12333] [21] [106] [110] [] [] []
[]
There was originally bug 7148457 filed for the same customer but was closed
as it it could not be reproduced.
The problem still does not seem reproducable in the customers environment as
the error occurs intermittently.
The violations that are causing the application to fail.
Customer is using three tier architecture.
1 db server 11.1.0.6, 19 middle tier servers running 11.1.0.6 JDBC driver,
and many browser clients.
=========================
Environment Information:
Database: Oracle DB 11.1.0.6 – 64 bit Oracle software on 64 bit operating
system
JDBC Driver: Thin 11.1.0.6
OS: x86_64 x86_64 GNU/Linux – Red Hat Enterprise Linux Server release 5
(Tikanga)
=========================
RELATED BUGS:
7148457 – same customer
=========================
REPRODUCIBILITY:
No – error occurs intermittently.
=========================
TESTCASE:
N/A
=========================
URL:
All stack traces can be uploaded
========================
WORKAROUND:
N/A
=========================
STACK TRACE:
File = XACTLY01_ora_13733.trc
— PROTOCOL VIOLATION DETECTED —
—– Dump Cursor sql_id=6naatzxy9kh1a xsc=0x2aaaac4af2f0 cur=0x2aaaabd41c90
—–
Dump Parent Cursor sql_id=6naatzxy9kh1a phd=0x44637cab8 plk=0x429f05928
sqltxt(0x44637cab8)=select position0_.POSITION_ID as POSITION1_13_,
position0_.VERSION as VERSION13_, position0_.NAME as NAME13_,
position0_.DESCR as DESCR13_, position0_.INCENT_ST_DATE as INCENT5_13_,
position0_.INCENT_END_DATE as INCENT6_13_, position0_.EFFECTIVE_START_DATE as
EFFECTIVE7_13_, position0_.EFFECTIVE_END_DATE as EFFECTIVE8_13_,
position0_.IS_MASTER as IS9_13_, position0_.MASTER_POSITION_ID as
MASTER10_13_, position0_.IS_ACTIVE as IS11_13_, position0_.CREATED_DATE as
CREATED12_13_, position0_.CREATED_BY_ID as CREATED13_13_,
position0_.CREATED_BY_NAME as CREATED14_13_, position0_.MODIFIED_DATE as
MODIFIED15_13_, position0_.MODIFIED_BY_ID as MODIFIED16_13_,
position0_.MODIFIED_BY_NAME as MODIFIED17_13_, position0_.BUSINESS_ID as
BUSINESS18_13_ from XC_POSITION position0_ where position0_.BUSINESS_ID=:1
hash=dbb804768d9c25ae6a2959ff7c99402a
parent=0x446379dc0 maxchild=12 plk=0x429f05928 ppn=n
cursor instantiation=0x2aaaac4af2f0 used=1222720227 exec_id=16804067 exec=2
child#10(0x42ee8a6c0) pcs=0x42e4f0e48
clk=0x429f05830 ci=0x42f679438 pn=0x422ea67e8 ctx=0x43624a188
kgsccflg=1 llk[0x2aaaac4af2f8,0x2aaaac4af2f8] idx=2b
xscflg=c0110676 fl2=5d000009 fl3=52222008 fl4=180
sharing failure(s)=100000000
—– Bind Info (kkscoacd) —–
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
kxsbbbfp=2aaaacb55820 bln=22 avl=00 flg=05
Frames pfr 0x2aaaacb55be0 siz=25528 efr 0x2aaaacb55b10 siz=25512
kxscphp=0x2aaaabd4b900 siz=984 inu=392 nps=344
kxscbhp=0x2aaaacb6d298 siz=984 inu=168 nps=48
Starting SQL statement dump
SQL Information
user_id=30 user_name=INCENT module=JDBC Thin Client action=
sql_id=6naatzxy9kh1a plan_hash_value=-1268437987 problem_type=4
—– Current SQL Statement for this session (sql_id=6naatzxy9kh1a) —–
select position0_.POSITION_ID as POSITION1_13_, position0_.VERSION as
VERSION13_, position0_.NAME as NAME13_, position0_.DESCR as DESCR13_,
position0_.INCENT_ST_DATE as INCENT5_13_, position0_.INCENT_END_DATE as
INCENT6_13_, position0_.EFFECTIVE_START_DATE as EFFECTIVE7_13_,
position0_.EFFECTIVE_END_DATE as EFFECTIVE8_13_, position0_.IS_MASTER as
IS9_13_, position0_.MASTER_POSITION_ID as MASTER10_13_, position0_.IS_ACTIVE
as IS11_13_, position0_.CREATED_DATE as CREATED12_13_,
position0_.CREATED_BY_ID as CREATED13_13_, position0_.CREATED_BY_NAME as
CREATED14_13_, position0_.MODIFIED_DATE as MODIFIED15_13_,
position0_.MODIFIED_BY_ID as MODIFIED16_13_, position0_.MODIFIED_BY_NAME as
MODIFIED17_13_, position0_.BUSINESS_ID as BUSINESS18_13_ from XC_POSITION
position0_ where position0_.BUSINESS_ID=:1
sql_text_length=806
sql=select position0_.POSITION_ID as POSITION1_13_, position0_.VERSION as
VERSION13_, position0_.NAME as NAME13_, position0_.DESCR as DESCR13_,
position0_.INCENT_ST_DATE as INCENT5_13_, position0_.INCENT_END_DATE as
INCENT6_13_, position0_.EFFECTIVE_START_DATE
sql= as EFFECTIVE7_13_, position0_.EFFECTIVE_END_DATE as EFFECTIVE8_13_,
position0_.IS_MASTER as IS9_13_, position0_.MASTER_POSITION_ID as
MASTER10_13_, position0_.IS_ACTIVE as IS11_13_, position0_.CREATED_DATE as
CREATED12_13_, position0_.CREATED_BY_ID as CRE
sql=ATED13_13_, position0_.CREATED_BY_NAME as CREATED14_13_,
position0_.MODIFIED_DATE as MODIFIED15_13_, position0_.MODIFIED_BY_ID as
MODIFIED16_13_, position0_.MODIFIED_BY_NAME as MODIFIED17_13_,
position0_.BUSINESS_ID as BUSINESS18_13_ from XC_POSITION posit
sql=ion0_ where position0_.BUSINESS_ID=:1
====================== END SQL Statement Dump ======================
*** 13:30:27.416
—– Error Stack Dump —–
ORA-3137: TTC protocol internal error : [1010] [] [] [] [] [] [] []
—– Current SQL Statement for this session (sql_id=6naatzxy9kh1a) —–
select position0_.POSITION_ID as POSITION1_13_, position0_.VERSION as
VERSION13_, position0_.NAME as NAME13_, position0_.DESCR as DESCR13_,
position0_.INCENT_ST_DATE as INCENT5_13_, position0_.INCENT_END_DATE as
INCENT6_13_, position0_.EFFECTIVE_START_DATE as EFFECTIVE7_13_,
position0_.EFFECTIVE_END_DATE as EFFECTIVE8_13_, position0_.IS_MASTER as
IS9_13_, position0_.MASTER_POSITION_ID as MASTER10_13_, position0_.IS_ACTIVE
as IS11_13_, position0_.CREATED_DATE as CREATED12_13_,
position0_.CREATED_BY_ID as CREATED13_13_, position0_.CREATED_BY_NAME as
CREATED14_13_, position0_.MODIFIED_DATE as MODIFIED15_13_,
position0_.MODIFIED_BY_ID as MODIFIED16_13_, position0_.MODIFIED_BY_NAME as
MODIFIED17_13_, position0_.BUSINESS_ID as BUSINESS18_13_ from XC_POSITION
position0_ where position0_.BUSINESS_ID=:1
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————–
—————————-
skdstdst()+41 call kgdsdst() 000000000 ? 000000001 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000000 ? 000000002 ?
ksedst1()+103 call skdstdst() 000000000 ? 000000001 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000001 ? 000000002 ?
ksedst()+39 call ksedst1() 000000000 ? 000000001 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000001 ? 000000002 ?
dbkedDefDump()+1076 call ksedst() 000000000 ? 000000001 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000001 ? 000000002 ?
ksedmp()+41 call dbkedDefDump() 000000003 ? 000000000 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000001 ? 000000002 ?
opiierr()+411 call ksedmp() 000000003 ? 000000000 ?
7FFF9F580088 ?
7FFF9F57EB70 ?
000000001 ? 000000002 ?
opitsk()+5353 call opiierr() 000000003 ? 000000000 ?
7FFF9F580088 ? 000000000 ?
0000003F2 ? 000000001 ?
opiino()+1026 call opitsk() 000000001 ? 000000000 ?
000000001 ? 000000000 ?
0000003F2 ? 000000001 ?
opiodr()+1178 call opiino() 00000003C ? 000000004 ?
7FFF9F587308 ? 000000000 ?
0000003F2 ? 000000001 ?
opidrv()+580 call opiodr() 00000003C ? 000000004 ?
7FFF9F587308 ? 000000000 ?
008202E40 ? 000000001 ?
sou2o()+90 call opidrv() 00000003C ? 000000004 ?
7FFF9F587308 ? 000000000 ?
008202E40 ? 000000001 ?
opimai_real()+145 call sou2o() 7FFF9F5872E0 ? 00000003C ?
000000004 ? 7FFF9F587308 ?
008202E40 ? 000000001 ?
ssthrdmain()+177 call opimai_real() 000000002 ? 7FFF9F587480 ?
000000004 ? 7FFF9F587308 ?
008202E40 ? 000000001 ?
main()+215 call ssthrdmain() 000000002 ? 7FFF9F587480 ?
000000004 ? 000000000 ?
008202E40 ? 000000001 ?
__libc_start_main() call main() 000000002 ? 7FFF9F5875E8 ?
+244 000000004 ? 000000000 ?
008202E40 ? 000000001 ?
_start()+41 call __libc_start_main() 000935D68 ? 000000002 ?
7FFF9F5875E8 ? 000000000 ?
008202E40 ? 000000002 ?
There are two errors reported above:
ORA-3137: TTC protocol internal error : [12333] [21] [106] [110] []
ORA-3137: TTC protocol internal error : [1010] [] [] [] [] [] [] []
The stacks are the same for both:
skdstdst, ksedst1, ksedst, dbkedDefDump, ksedmp, opiierr,
opitsk, opiino, opiodr, opidrv, sou2o, opimai_real, ssthrdmain,
main, __libc_start_main, _start
According to the TAR, the error the client application sees is:
Exception Message : PreparedStatementCallback; uncategorized]; SQL state [72000];
SQLException for SQL [
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.