Any oracle client that is used to send data traffic from your database server to the client (and back), should be at the same release as the database. You know that if you are on database 11.2.0.4 64 bit linux, then your clients should also be on 11.2.0.4. There are many reasons for this, but at the end of the day it comes down to security, stability and performance.
Even your deployment server should be on the exact same client patch release. It’s a 32 bit client too (weird I know). It’s a 32 bit client on the enterprise servers too.
I’ve recently done a bunch of stress testing and load testing of JD Edwards and have seen a number of sites with an ORA-03114 / ORA-03113 and the associated server side errors for these disconnects. Sure, quite often these are firewall and network related – but you should be able to make this predictable. I had a situation where the a few connections would just go down after 40 minutes, 15 minutes. Sometimes with a spectacular fail and sometimes just a retry and things would be back to normal.
Server side looked like this:
Dumping 'Buffer dump info:' addr=0xc6c4760 size=92 bytes
Dump of memory from 0xc6c4760 to 0xc6c47bc
00C6C4760 00000104 01BE1B00 7B000000 00000005 [...........{....]
00C6C4770 0000D300 00000300 D8000000 09000038 [............8...]
00C6C4780 93440000 00000016 00000000 00001D00 [..D.............]
00C6C4790 00000001 00000000 00000000 00000000 [................]
00C6C47A0 4F190000 302D4152 33303431 6F6E203A [...ORA-01403: no]
00C6C47B0 74616420 6F662061 0A646E75 [ data found.]
hstflg: 0x40202d81
hstcflg: 0x00000000
hstpro: 6
And in the alert log, a TTC matching EVERY ORA-03114
Mon Apr 11 06:36:15 2016
Archived Log entry 4238 added for thread 1 sequence 4238 ID 0x176a252 dest 1:
Mon Apr 11 06:39:17 2016
Errors in file /rdsdbdata/log/diag/rdbms/vlinest_a/VLINEST/trace/VLINEST_ora_1972.trc (incident=153033):
ORA-03137: TTC protocol internal error : [12333] [7] [2] [195] [] [] [] []
Incident details in: /rdsdbdata/log/diag/rdbms/vlinest_a/VLINEST/incident/incdir_153033/VLINEST_ora_1972_i153033.trc
Mon Apr 11 06:39:20 2016
Dumping diagnostic data in directory=[cdmp_20160411063920], requested by (instance=1, osid=1972), summary=[incident=153033].
Mon Apr 11 06:39:21 2016
Sweep [inc][153033]: completed
Sweep [inc2][153033]: completed
It seems that there was a very relevant patch listed under bug 18263924, this is a client OCI fix which is supposed to resolve these client and server errors. Wow, I think we are getting to the point of this entry, it’s about opatch, and determining the exact release of your oracle software.
$ /u01/app/oracleclient32/product/11.2.0/client_1/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 11.2.0.3.4
Copyright (c) 2012, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracleclient32/product/11.2.0/client_1
Central Inventory : /home/jde910/oraInventory
from : /u01/app/oracleclient32/product/11.2.0/client_1/oraInst.loc
OPatch version : 11.2.0.3.4
OUI version : 11.2.0.4.0
Log file location : /u01/app/oracleclient32/product/11.2.0/client_1/cfgtoollogs/opatch/opatch2016-04-18_10-22-46AM_1.logLsinventory Output file location : /u01/app/oracleclient32/product/11.2.0/client_1/cfgtoollogs/opatch/lsinv/lsinventory2016-04-18_10-22-46AM.txt
--------------------------------------------------------------------------------
Installed Top-level Products (1):Oracle Client 11g 11.2.0.4.0
There are 1 products installed in this Oracle Home.
Interim patches (1) :Patch 18263924 : applied on Mon Apr 18 10:14:41 EST 2016
Unique Patch ID: 20096960
Created on 14 Apr 2016, 12:39:07 hrs PST8PDT
Bugs fixed:
18263924
--------------------------------------------------------------------------------
OPatch succeeded.
You can see from the above that I’ve just executed opatch lsinventory (in my case from the patch directory). And it’s told me everything that I need to know about the software and patch level. for the oracle home that the executable is in.
You basically enter the same command (I need to qualify opatch with the path), to opatch apply the patch. Do this from the directory that you “unzipped” the patch into.
Another command that you might want to run is opatch prereq CheckConflictAgainstOHWithDetail -ph ./ to check everything is okay before the apply.
Note that in general you will probably need to stop JD Edwards, as any locks on the files is going to prevent opatch from running properly.
1 comment:
Shannon - thanks for posting this. We have been waiting for Oracle to release a 32-bit version of this patch since early February. It is nice to know we're not the only E1 instance with the problem.
Post a Comment