Re: ORA-03113: end-of-file on communication channel

From: PaulCinVT <paulcinvt_at_aol.com>
Date: 2000/05/18
Message-ID: <20000518122129.05836.00000594@nso-ch.aol.com>

ORA-03113 And ORA-03114 On Desktop Platforms

Document ID: 1003596.6

Title: ORA-03113 and ORA-03114 On Desktop Platforms

Product: SQL*Net

Product Version: Generic

Platform: MS-DOS IBM & Compatible, Microsoft Windows, OS/2-V1.x, OS/2-V2.x, Intel Windows NT

Information Type: ADVISORY

Impact: HIGH

Abstract: This bulletin explains how to handle an ORA-3113 and ORA-3114 on desktop platforms

Keywords: Gupta, SQLWindows

ORA-03113 And ORA-03114 On Desktop Platforms

What does ORA-03113 "end-of-file on communication channel" really mean?

ORA-03113 is the most common catchall error. It basically means that communications were lost for an unexpected reason. It is usually followed by ORA-03114 "not connected to ORACLE".

As it turns out, the most common reason is that the Oracle shadow process on the server died unexpectedly. So, if a running process were to suddenly encounter an ORA-03113 and/or 3114, the first place to check is the alert.log on the server to see if any other Oracle errors occurred.
Next most common cause of ORA-03113 is that the SQL*Net driver was not linked into the Oracle executable on Unix. While the listener successfully received the connection and passed it to the Oracle shadow process, the shadow process would fail to respond in any way because it would not know how to. So the client will see an ORA-03113 at connect time.
Third most common cause is a machine crash or network failure at the server side.
One less common cause has been observed is when there are two servers with the same node names on the same network.
ORA-03113 has also been noticed where the a TOKEN RING card has the Shared RAM size set to 8KB rather than 16KB. If you are using a TOKEN RING card check the shared buffer size and try increasing it.
ORA-03113 also occurs when INIT.ORA parameters CONTEXT_AREA and CONTEXT_INCR are set to a value of 4096. Increasing the value to 8192 resolves the 3113. (RDVMS V6 only)
ORA-03113 also occurs when there are duplicate IP addresses on the network. To find the duplicate addresses turn off the unit that is getting the 03113 and ping its IP address. If the ping responds then you have to find the offending unit.
If an ORA-03113 error occurs intermittentlly on comparatively large select statements through SQL*DBA for OS/2 or when performing a query through SQL*DBA, try setting the default buffer size to 4096, especially if issuing an order by causes no problems but going through Q&E or SQR hangs the machine.
If using FTP V2.11 and running a large SQL*Plus script with over 38 variables of mostly character data types, check the lan drivers. The dxmc driver loads addressing for token ring adapter has an option to save memory (through IBM lan suppport program).

        r parameter (r: reduced)  
        t parameter (t: tiny)

You must specify the r and t parameter for the dxmc drive.

It all comes down to the fact that the client went out to read some information from the server and suddenly found out the connection was no longer there.

ORA-03113 is just a symptom of a larger problem that will require more diagnosis to track down. Hopefully, the above information will lead you in the right direction to find the solution.

To debug an ORA-03113, it is a good idea to attempt the same operation while doing a loopback, i.e can any tool on the server connect using the same connect string as they specify from the Desktop client? If the same problem occurs doing a loopback, then you know the problem resides on the server side and not on the Desktop client side.

To perform a loopback invoke SQLPLUS or SQLDBA from the server, and at the SQLPLUS or SQLDBA prompt on the server type:

CONNECT USERNAME/PASSWORD_at_t:<servername>/<portnum>:<sid>

For example, if you are getting an ORA-03113 issuing a certain query from SQL*Plus on DOS while connected via SQL*Net TCP/IP to a Unix server, try a loopback by invoking SQL*Plus on the Unix machine and use the same "t:<servername>:<sid>" connect string and then issue the same SELECT statement.

This error is sometimes received intermittently with applications written with Gupta SQLWindows. Apparently, the problem is due to some buffer being used by the Gupta product. This buffer is used to fetch data returned by a query on the client side. The default value for a parameter called FETCH ROW (in SQLWINDOWS) is 20. Lowering this to something like 15 seems to work fine.

Oracle WorldWide Support

Paul in VT Received on Thu May 18 2000 - 00:00:00 CDT