请问高手：end-of-file on communition channel错误怎末处理？

Solution Description:  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".

1.  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.

2.  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.

3.  Third most common cause is a machine crash or network failure at the
    server side.

4.  One less common cause has been observed is when there are two servers with
    the same node names on the same network.

5.  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.

6.  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)

7.  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.

8.  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.

9.  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@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.

10. If you're getting an ORA-03113 on long queries with SQL*Net SPX protocol
    adapter v2.0.14.x.x on Windows or any version of the adapter v2.0.15 up to
    2.0.15.0.4 on Windows, you are strongly encouraged to upgrade to
    v2.0.15.0.5 of the adapter with SQL*Net v2.0.15.0.3.  The ORA-03113
    usually occurs after a 120-second delay in the query.

    Note: If your server is running the Unixware-Oracleware configuration,
    you will need to get the v2.0.15.0.5 SPX Adapter for Windows patch to go
    with your v2.0.14 SQL*Net for Windows.  This configuration is only
    supported for Unixware-Oracleware customers.

11. 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.

12. If you are receiving an ORA-03113 error when running SQL*Net TCPIP v1
    from Windows clients to a Netware v3.11 file server, and you are using
    the TCPIP.NLM V1.00, then you must obtain the updated TCPIP.NLM (V2.02M).

    It is also recommended to obtain the latest library patches for the
    NetWare file server (currently available in the NOVFILES forum on
    CompuServe as LIBUP4.EXE).

    Many enhancements and bug fixes have been made to the later TCPIP.NLM that
    Novell is currently shipping in their TCP188.EXE patch file located on
    their FTP server or located in the NOVLIB forum on CompuServe.

    Starting with SQL*Net TCP/IP 1.1.6.20 and later, TCPIP.NLM V2.02M is
   needed for Oracle's TCP/IP driver to properly set the keepalive timers.

    The latest SQL*Net V1 TCP/IP for NetWare to Date is 1.1.6.29 and that is
    also recommended for any customer with ANY earlier release of the V1
    listener for NetWare.

13. Check that your network router is not filtering the data.

调试易

请问高手：end-of-file on communition channel错误怎末处理？

解决方案 »