random disconnects from oracle

[Dave Chamberlin]

Hello,
I am testing an upgrade from 10.7 apps with oracle8i database. I have recently copied my oracle 8i database and the old appltop from the old server running HPUX 11.0, to the new server running 11.11. I relinked the oracle8 executables. The database and apps are working fine except at random times, users get disconnected. From toad, the error is a TNS error ...cannot resolve service name. From the oracle apps, the app loses its conection and evetually gives ORA-3113 and ORA-3114 messages. Working on the server I have had no problems running patches or sql queries. I can find no errors in oracle log files, listener log files, PC event viewers etc. I am looking for some idea on where to start. Is this an oracle or OS issue?

[TwoProc]

Sounds like your dropping your name from DNS on occasion. Just to rule it out - try putting the server name (that you're using in your tnsnames.ora file) in your host file. If the situation continues, I'd look for a network duplex issue on the new server. Possibly you've got the network switch configured at half duplex (or auto) and maybe the server configured at full duplex, - or vice-versa. I know that both sides being auto should work fine, but I prefer to set both sides to the same and not use auto. A simple truth test for this would be evident by huge differences in the transfer rates using something simple like ftp'ing a 1Gig file to your old server and to your new server and comparing the difference. If the difference is like an order of magnitude, then that's probably the issue. Another thing you could do to eliminate dns or name host issues would be to edit the tnsnames.ora file and change the server name to an IP address - this isn't great for long-term support - but it is an easy way to troubleshoot.

[Dave Chamberlin]

thanks for the reply. I have already has the IP address set in the TNSNAMES files -so I dont think that that is the issue. As for the server, it has a 1G ethernet adaptor set at auto. The switches in our data center are all set at auto, and as I understand it the server setting should be the same as the switch setting.I did try moving the server t a newer switch to see if that makes a difference.

[TwoProc]

Dave, well you have ruled out DNS name lookup. But, the fact that have both sides set at auto *could* be your problem. Try doing file transfer to you old system vs the new as I indicated, or better yet, try setting both sides to full duplex and see if the problem goes away.

Also, the TNS error - cannot resolve service name should only occur when trying to make a connection - that shouldn't be your error when you're getting dropped from Toad. Is this the case? If so - then the only error you may be experiencing is the drop from the apps users that are on the forms server tier.

If this is the case (only apps users are getting dropped, not direct sqlplus users), then the problem could be a nagging bug that I experienced waayyy back then that was due to a memory leak. From the forms server, run glance and grab a form server process that is pretty active. Look specifically at the size of the data segment while the user is on (if you can - call the user and ask them to navigate into a form, out of the same form, and then back into the SAME form, querying the SAME data, over and over again). If you've got the bug that I'm thinking of, it's a memory leak that manifested itself in the forms server program that each construction and destruction of the objects from the forms server point of view - were not re-used, but totally recreated. What you would see is that the size of the data segment from the running program hits the limit of per-user process of data segment in the kernel (maxdsiz). The result was the user saw first "end-of-file on communication channel", and then either/or/and a "network communication error" followed by "not connected to Oracle". Looks very similar to what you're seeing from the ORA- error codes you posted. The fix was a patch that came out around Sep/Oct/Nov of 99 (the quarter before Christmas for sure).

Now, the problem is, I don't know if you can get a patch that old to fix your issue. But, good luck with it anyways. If you're desperate - I might be able to get my hands on a patch repository from tape from back then and see if I can identify it. Let me know if you definitely see the problem(s) as I've described, and if you can't find/get the patch, maybe I can get it for you.

[Eric Antunes]

Hi Dave,

I think I'd this kind of issue once.

Are you running Oracle E-Business Suite? If so, check that the *.jar files are the same version in $FND_TOP and $ORACLE_HOME. If there are not, this must be your problem.

Regards,

Eric Antunes

[rick jones]

How Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of late collisions. On
the side running full-duplex you will see things like FCS errors.
Note that those errors are not necessarily conclusive, they are simply
indicators.

[Dave Chamberlin]

Thanks for the replies and suggestions. As it turns out, all of our data center switches are set to auto negotiate, and the server is as well. The move of the servers connection to the newest switch was the solution to the problem, though I cannot say why.