17,380
社区成员
发帖
与我相关
我的任务
分享请问高手：end-of-file on communition channel错误怎末处理？
我现在有一台机器，先安装winnt40,然后安装oracle7.3,再把oracle中database文件夹中的所有文件删除，把别人同样软件环境下作好的oracle下database文件夹中的所有文件拷贝到我的oracle中database文件夹中；然后在运行svrmgr23,运行connect internal/oracle,都成功，但接下来执行startup mount却报告end-of-file on communition channel错误，我应该怎末办？请高手不吝赐教！万分感谢！！！
...全文
请发表友善的回复…
发表回复
IronPromises 2002-09-18
- 打赏
- 举报
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.
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.
luckysxn 2002-09-18
- 打赏
- 举报
重新启动机器,不一定好用的，有可能是你的CONTROL文件坏了。
请检查一下吧。
请检查一下吧。
qiuyang_wang 2002-09-17
- 打赏
- 举报
重新启动机器，万事大吉。
jiezhi 2002-09-17
- 打赏
- 举报
你重新连接一下，如果不行的话
把数据库服务重新启动一下，然后重新连接
把数据库服务重新启动一下，然后重新连接
