imp 导入报错
IMP-00058: 遇到 ORACLE 错误 12571
ORA-12571: TNS: 包写入程序失败
IMP-00058: 遇到 ORACLE 错误 3114
ORA-03114: 未连接到 ORALCE
IMP-00000: 未成功终止导入imp 语句为
imp aa/bb@cc file=F:/test.dmp tables=test log=F:/test.log buffer=31200000 indexes=n feedback=10000 ignore=y commit=y analyze=n grants=y是数据库的问题还是网络的问题啊
谢谢大家啊
IMP-00058: 遇到 ORACLE 错误 12571
ORA-12571: TNS: 包写入程序失败
IMP-00058: 遇到 ORACLE 错误 3114
ORA-03114: 未连接到 ORALCE
IMP-00000: 未成功终止导入imp 语句为
imp aa/bb@cc file=F:/test.dmp tables=test log=F:/test.log buffer=31200000 indexes=n feedback=10000 ignore=y commit=y analyze=n grants=y是数据库的问题还是网络的问题啊
谢谢大家啊
主题: ORA-12151 or ORA-12571 Errors Connecting to Database on Windows
文档 ID: 注释:71921.1 类型: BULLETIN
上次修订日期: 23-OCT-2008 状态: PUBLISHED Checked for relevance on 23-OCT-2008.PURPOSETo provide an overview of how to verify and handle errors ORA-12151 and
ORA-12571.SCOPE AND APPLICATIONThis notes applies to anyone facing intermittent SQL*Net read and write error
when using Oracle SQL*Net or Net8 on Windows platforms.==============================================================================--------------------------------------------
ORA-12151 and ORA-12571 errors on Windows NT
--------------------------------------------Intermittent SQL*Net TCP/IP read and write errors are sometimes encountered
on Windows NT. The underlying reasons of these errors are a synchronization
error in the TCP/IP layer on Windows NT. To help prevent this kind of error, a
few things can be adjusted to help the synchronization:1. TCP.NODELAY parameter This parameter may be added to the PROTOCOL.ORA file in the
NETWORK\ADMIN directory. In most cases, TCP/IP data sent across the network is buffered until at
least a complete network packet can be send. This means that in certain
cases, commands are not issued directly, and kept buffered until some other
data can be sent as well. This has the potential to generate time-outs and
errors. To avoid this, the delay can be switched off. tcp.nodelay = yes2. DISABLE_OOB parameter Another possible cause of ORA-3113/ORA-12151 is caused by a known issue
affecting the TCP/IP stack on Sun Solaris, for which the only available
workaround is to disable out-of-band breaks. If the client is Solaris, see
the following notes: Note 1068560.6. Note 1016295.4 and Note 120498.1.2. Disabling AUTOMATIC_IPC On client PC's, checking for IPC connections is pointless as there
is usually no database residing on them. To save time during the connection
phase, set AUTOMATIC_IPC=OFF in the SQLNET.ORA file.
3. NAMES.DIRECTORY_PATH to force use of TNSNAMES and/or ONAMES If you have a static environment, it is recommended to explicitly specify
this parameter in the SQLNET.ORA file. The parameter specifies how
the Transparent Network Substrate (TNS) resolution is to take place. By default, if this parameter is not present - the SQL*Net layer
will first check if there is a Names Server anywhere on the network, after
which it checks for the existance of local TNSNAMES.ORA file. If you only have a TNSNAMES.ORA file, it is recommended to explicitly specify
the parameter to avoid unecessarily searching for Names Servers - this not
only speeds up TNS resolution, but also prevents unecessary SQL*Net trace
file generation when SQL*Net tracing is enabled. The parameter value is a comma separated list, with the possible values of:
TNSNAMES (TNSNAMES.ORA), ONAMES (Oracle Name Server) and HOSTNAME
(Directory Cell Environment (DCE)).
4. TCP/IP timeouts on NT The default retransmission count on Windows NT is 5, before it detects that
the network is down. With the value of 5, the actual timeout is
aproximately 15 seconds. This default value can be easily increased to a higher value by modifying
TCP parameters in the Windows registry i.e. HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
TcpMaxDataRetransmissions REG_DWORD "number" By default, the parameter is not present in the registry. If modifying the
parameter for the first time, it will need to added. The parameter can be useful on both client and data server. The recommended
first course of action is to add the parameter on the machine generating the
SQL*Net errors. If problems persist, add or modify the parameter in the
registry of the data server or other machine/s.
5. TCP/IP keepalive on NT KEEPALIVE is an extension to TCP/IP which enables the closing of dead
connections that are no longer being used. Problems can occur when the server does not close a connection after a
client process has disappeared or terminated abnormally. This typically
happens when a user switches off or reboots their machine whilst still
connected to Oracle. Note: this is not an Oracle problem, but a limitation of TCP/IP, which has
no way of knowing whether a remote connection has disappeared. This feature is enabled by default on Windows NT, however the deafult value
is 2 hours. Problems can arise however if the timeout value is set too low
for some heavily used or slow networks. Under these conditions, the
KEEPALIVE registry value can be used to specify a KEEPALIVE value before a
connection gets cut.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
TCP/IP
Parameters
KeepAlive REG_DWORD "number" A value of 10 minutes is a typical value used. Again, the parameter can be useful on both client and server.
Start with the machine generating the error, and if needed, add it to the
data server or other machine/s.
6. TCP/IP timeouts on Windows 95/98 The same parameter may also be used under Windows 95. It performs the same
functionality, however only the location of the parameter is different. HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Winsock
Parameters
TcpMaxDataRetransmissions REG_DWORD "number" Again, the parameter is not present in the registry by default. This means
the parameter must be added to the registry the first time it is modified.
7. SDU & TDU parameters Part of the problem may be the sequence of information that is transmitted.
If there are disruptions in the sequence, errors ORA-12151 and ORA-12571 can
also appear, alerting the application that not all information has been sent
across the network succesfully. The sequence of information is determined by the amount of data the program
is sending and the actual size the protocol can send across the network
at a time. The more data the program wants to send in one 'go', the more sequences and
transport packets will have to be made. By default, SQL*Net uses a Session Data Unit SDU) of 2048 bytes (2Kb)
and a Transport Data Unit (TDU) of 32768 (32Kb) bytes. On standard Ethernet
connections, without modification, the SDU is 1500 bytes and TDU 8760 bytes. With these values, each data request made by SQL*Net must be split into
several smaller packets to be able to be transmitted.
Therefore, where errors occur, it is recommended to minimise the creation of
unecessary additional packets by synchronising the SDU and TDU parameters at
the SQL*Net level with those of the actual network topology/protocol in use. To use non-default SDU/TDU values, the parameters must be configured within
both client and server SQL*Net configuration files as follows: TNSNAMES.ORA:
-------------
ORCL.WORLD =
(DESCRIPTION =
(SDU=1500)
(TDU=8760)
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL=TCP)(HOST=foobar)(PORT=1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
) LISTENER.ORA:
-------------
...
SID_DESC_LISTENER =
(SID_LIST =
(SID_DESC =
(SDU = 1500)
(TDU = 8760)
(SID_NAME = ORCL)
)
) For additional information regarding SDU and TDU parameters, refer to
Note 44694.1: SQL*Net Packet Sizes (SDU & TDU Parameters).
8. Setting a new TDU size on Windows NT You can modify the TDU size on Windows NT, via the TcpWindowSize parameter: HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
Tcpip
Parameters
TcpWindowSize REG_DWORD "number"
Additional information about Windows NT network parameters:
-----------------------------------------------------------Q120642: TCP/IP & NBT Configuration Parameters for Windows NT
http://support.microsoft.com/support/kb/articles/Q120/6/42.aspQ140375: Default MTU Size for Different Network Topology
http://support.microsoft.com/support/kb/articles/Q140/3/75.asp
==============================
tnsping 一下，看看是不是通。
先解决数据库的可访问性问题。
比如表空间和用户都建了吗?还有grant了有没有?
---------------------------------
你先保证网络连接数据库没有问题吧
然后再分析语法的问题
数据库都连不上,那肯定是导入不成功的