Re: SQLNET V2 TCP/IP - erratic behaviour during connection

cooper_at_seismo.CSS.GOV (Dale Cooper) writes:
|> Anyhow, we are running V6.0.37 on a Solaris 2.3 machine. Things will
|> start out just fine as folks and applications will run for hours to days
|> without interruption. Then all of the sudden orasrv either whacks out
|> by entering an endless Run state on the system or the process will simply
|> hang. In either case, no other processes will be serviced until I either
|> kill then restart the orasrv process or kill off all of the connected
|> processes. In the latter case orasrv frees itself and goes along on its
|> merry way. Of course there are no error messages generated in either
|> rdbms/log or tcp/log (orasrv.log) so it is currently impossible to find
|> out exactly which process is hung. Again, with the killing of remote
|> processes, the order of the kill is meaningless. I can kill the older
|> procs first, or the younger procs first. But as soon as the last one is
|> killed, orasrv go off and begins servicing connections as if nothing ever
|> happened.

Couple of suggestions:
1) Try setting the timeout option on orasrv. On Unix, you'd say

   'tcpctl timeout 30' or something along those lines. This just    means that if orasrv receives a connect request, but does not    read data within a certain time period, give up on the connect    request and process the next one. (Once a connection to a server    is established we rely solely on the keepalive mechanism of TCP/IP

• until SQL*Net V2.1 anyway). 2) Maybe try using the orasrv that ships with 7.0.15 or higher.

There are a few bugs which have been fixed though nothing comes to the top of my head that is more than a fuzzy match to what you are experiencing.

You might be able to get more info by getting a stack trace of the orasrv process when it goes haywire. I forget if Solaris has a way to attach to a running process with a debugger or if you need to resort to a third party tool.

Feel free to run the above by support whether you get the extra information or not. Received on Sat Sep 10 1994 - 01:18:48 CEST