Solved

Got ORA-12571 TNS: packet writer failure when installing 9.2i on xp.

Posted on 2004-08-20
4
28,443 Views
Last Modified: 2013-12-11
I'm setting up in a newly created PC environment.  I'm installing Oracle 9.2i.  When it gets to the phase where it starts up the database I get the error in the title.  I gave it a retry, same effect.  I accepted the defaults.  I'm installing the enterprise edition.

There was a posting of this same problem here from January.  There was no solution among the answers.  Does anyone know what this is about?  I can't seem to be able to register at OTN to try to find a solution.  Something must be wrong with their registration page.

Would appreciate help.  Didn't have any problem installing at home  last year.

Mike Ryan at Bladelogic
0
Comment
Question by:jmichaelryan
4 Comments
 
LVL 7

Expert Comment

by:BobMc
ID: 11874182
Mike,

Ora-12571 is a catch-all network error, which unfortunately doesnt offer much help as to the cause. I've attached some suggestions from Oracle below, but the way I normally get to the bottom of this type of problem, is to enable tracing in SQLNET.ORA, and hope for a more meaningful message.

Does the installation complete, except for the startup of the database?

PURPOSE
 
To provide an overview of how to verify and handle errors ORA-12151 and
ORA-12571.
 
 
SCOPE AND APPLICATION
 
This 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 = yes
 
2. 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. The issue is discussed in  
   detail in [NOTE:1068560.6]. [NOTE:1016295.4] and [NOTE:120498.1] discuss
   this little known and used parameter.
 
 
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.asp
 
Q140375: Default MTU Size for Different Network Topology
  http://support.microsoft.com/support/kb/articles/Q140/3/75.asp

0
 

Author Comment

by:jmichaelryan
ID: 11874679
We have solved the problem by commenting out all three lines in sqlnet.ora, viz.:

# SQLNET.ORA Network Configuration File: C:\oracle\ora92\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.

#NAMES.DEFAULT_DOMAIN = int.bladelogic.com

#SQLNET.AUTHENTICATION_SERVICES= (NTS)

#NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

These were generated by the install process looking around at my system.

Thanks for the extensive reply.  I'm sure it will come in handy for many other 12571 failures.  They seem to pop up around here.

Mike Ryan
0
 
LVL 1

Accepted Solution

by:
DarthMod earned 0 total points
ID: 12142973
Submitted to PAQ with points refunded (500)

DarthMod
Community Support Moderator
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Single ERP VS muttiple Application or Systems 6 38
select query - oracle 16 81
oracle query help 18 75
Oracle Subquery bad Join 11 42
Note: this article covers simple compression. Oracle introduced in version 11g release 2 a new feature called Advanced Compression which is not covered here. General principle of Oracle compression Oracle compression is a way of reducing the d…
How to Unravel a Tricky Query Introduction If you browse through the Oracle zones or any of the other database-related zones you'll come across some complicated solutions and sometimes you'll just have to wonder how anyone came up with them.  …
This video shows information on the Oracle Data Dictionary, starting with the Oracle documentation, explaining the different types of Data Dictionary views available by group and permissions as well as giving examples on how to retrieve data from th…
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now