zawierta wrote:For Quick process you have to check With your network administrator Firewall , Switch , ... to prove everything is Ok
But I don't think that problem is in middleware - middleware works fine with prod db. I think the problem is in listener and network handling on db side.
zawierta wrote:Once the client has established a session within the DB,
Ok, maybe Oracle DB is victim... I'm just asking you to help me trace the problem. Now I guess, that it can be different OS. If so, I'll reinstall solaris tomorrow and try to solve that, but that is whole day of dirty job - SAN/FC network, multipath, zone creation and so on, so reinstalling Solaris is on the last place in my TODO list.
Can I somehow force listener to generate a lot of debug logs?
zawierta wrote:You know what I do whenever anyone says "trust me?" You know what happens to my opinion of the ability of netadmins to diagnose a database issue when they can't even show the error message? You know what they say about assume? Why should we simplify, when that could leave the actual error out of the problem domain? [url http://bit.ly/XK1HSB]BAAG that!
Thanks for response.
I'm also network admin - trust me, it is no network problem. It is complex environment, but to simplify let's assume that:
PROD_DB - 10.0.0.11Well hells's bell's, it sounds like you have a jar file jdk version mismatch or classpath problem. Of course "sounds like" is probably one of the less reliable tracing methodologies. Why don't you post the actual error given back? Are there no log files on your middleware? Do you not have support? Have you searched the support site for the connection reset error?
DEV1_DB - 10.0.0.21
DEV2_DB - 10.0.0.22
DEV3_DB - 10.0.0.23
PROD_AppSrv - 10.0.0.14
DEV_AppSrv - 10.0.0.8
DEV_AppSrv is hosting three deploys of the same application, each connected to different DEVx_DB.
Everything is on the same subnet, there is no firewall, everything is on the same switch (enterprise-level cisco).
Prod_DB - Solaris10(M4000), 220.127.116.11
DEV1_DB - Solaris10(old sparc machine) - db 10.2.0.5 (this one was frozen with upgrade due to problem with resetting connection)
DEV2_DB - Solaris11(T5220), 18.104.22.168
DEV3_DB - Solaris11(T5220), 22.214.171.124
Now, how it works:
PROD_APP + PROD_DB - fine
DEV_APP + DEV1_DB - fine
DEV_APP + DEV2_DB - reset
DEV_APP + DEV3_DB - reset
As you can see, middleware seems to be ok, when dev2 and dev3 was 10g on old machine (like dev1 does now) - all three instances were fine.
Also upgrading from 10 to 11g2 causes no problem, because I'm running my prod instance on 11g on extremely high load (100 times bigger than dev) and it works.
Only difference between prod_db and dev2/3_db is, that base os is Solaris11 on dev systems. Of course I can install 11gR2 on "old machine" (where DEV1_DB is working fine), but I guess it is not a good way. Downgrading Solaris11 to Solaris10... well, if everything else fails :)
That's all about my env.
In next post I'll give you more info.