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

In article 18797 of comp.databases.oracle gopi_t1_at_verifone.com (T.K. GOPIKRISHNA, software,BLR,01191812-269920) writes:

>Hello,
>
>We have been experiencing pretty randomly the problem of not being able to
>connect to the oracle database using the sqlnet V2 on TCP/IP on a unix box.
>The message I get when I try to connect looks something like "end-of-file on
>communication channel". I checked up that the listener is running on the
>configured TCP port. The problem clears up if I stop the listener and
>restart again. I am able to connect thereafter and use the database.
>
>I am not able to get the exact sequence that can reproduce
>this problem. Has anyone out there got this kind of problem? What is the
>workaround or is there something in configuration which i have missed out.
>Please help me out in getting over this problem.
>
>Thanks
>gopi

Then in article 18812, rmanalac_at_oracle.com (Roderick Manalac) writes:

gopi_t1_at_verifone.com (T.K. GOPIKRISHNA, software,BLR,01191812-269920) writes: |> Hello,
|> ... [original text deleted]  

>Interesting... can you tell us the exact platform and version of Oracle
>you are running? The fact that you are getting "EOF on ..." (aka ORA-3113)
>generally means you are at least reaching the listener. I can only guess
>that it's failing to spawn a shadow server for you or redirecting you to
>a non-existent dispatcher if you are configured for MTS. Neither of these
>ring a bell for me.
>
>Roderick Manalac
>Oracle Corporation

I've had similiar peculiar behavior with SQL*Net V1.2 (orasrv) lately with our V6.0.37/Solaris 2.3 instance. I'll give you the specifics and the behavior for your information. I would like to know if this is a known bug and if there is a subsequent patch for this "problem." It has been a thorn in my side for a couple of weeks now and it would be nice to nip it in the bud as this is our production system and it's getting pretty old getting called at home on a Saturday afternoon and being asked to fix it especially after I've consumed a fair amount of homemade adult beverages. Of course the consumption of additional adult beverages could be traced directly to this problem, but that's another issue entirely.

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.

This has become a serious problem as our system is real-time and we demand uninterrupted access. I have delayed calling tech support as I am unable to trap any documented clues to this problem other than innane client error messages. The conditions that Gopi declares are eseentially the same type of behavior that we see. The only error messages we see are processes such as EXPort that try to connect and are timed-out.

	EXP-00008: ORACLE error 6108 encountered
	ORA-06108: NETTCP: connect to host failed
	EXP-00222:
	System error message: 60
	EXP-00000: Export terminated with error

The 6108 refers to the host orasrv process being down or Ethernet being hosed. This of course is rubbish. The Ethernet is fine, orasrv is jammed with a process that we cannot identify.

Any help would be appreciated in this matter.

Thanks in advance,

Dale Cooper,
Lowly DBA for the Center for Seismic Studs in lovely Arlington, VA Received on Fri Sep 09 1994 - 18:02:54 CEST