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

In article <34qpc2$mra_at_dcsun4.us.oracle.com>, rmanalac_at_oracle.com (Roderick Manalac) writes:    

|>
|> Same error but different circumstances imply that this is a different
|> problem. Unfortunately, ORA-3113 is the generic catch all problem
|> when a client wants to perform a network IO to the server and finds
|> that it has rudely "hung up the phone without saying goodbye". Sort
|> of like getting the silent treatment from an SO and being left to
|> figure out what went wrong (not that it's ever happened to me).
|>
|> In the case where the unexpected EOF happens well after a connection
|> has been established, the problem is not with the listener since it
|> should be clear out of the picture at this point. Either the server
|> died unexpectedly or the network itself freaked out. If it was the
|> server, it is generally good about leaving trace file (suicide note?)
|> on the server if not some indication in the alert.log file.
|>
|> If it's the network, debugging becomes really difficult. In one case
|> it turned out to be a flaky router that was messing up packets of a
|> particular length to a particular address under a particular load.
|> That's an extreme case though.
|>

We have traced 3113 errors to dead shared server processes, but 99% of the time, the shared servers show no indication of any troubles whatsoever when the problem occurs. How does the client determine if the server has "hung up the phone without saying goodbye"? Is it based on a timeout? If so, can the value for the timeout be set?

Ian MacGregor
Stanford Linear Accelerator Center
(415) 926-3528
ian_at_slac.stanford.edu Received on Wed Sep 14 1994 - 18:43:20 CEST