Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: ORA-12571 -Solution

RE: ORA-12571 -Solution

From: Abdul Aleem <dmit_at_beaconhouse.edu.pk>
Date: Tue, 18 Feb 2003 22:43:47 -0800
Message-ID: <F001.00551022.20030218224347@fatcity.com> 





Brad,



Thank you for you detailed reply. I tried with copying configuration files,
then by setting tcp.nodelay also I tried other setting as suggested in the
note.



The solution was rather simpler. While reading your mail, I suddenly
recalled my teacher's sentence when he was explaining connect string that,
"For local connections (same box) it (Oracle) uses bequeth protocol". I did
that and it worked fine. Last night I rebooted the machine several times and
tired several forms and reports all with success.



Thank you once again



Aleem



 -----Original Message-----

Sent:	Monday, February 17, 2003 6:47 PM
To:	'dmit_at_beaconhouse.edu.pk'
Subject:	ORA-12571





With Forms6i and a Database on a stand alone machine, remember you have two
clients.



It is likely that the client from 6i has a configuration problem.



Try copying the SQLnet.ora and tnsnames.ora from the 9i
ORACLE_HOME/network/admin



to the network/admin directory in the 6i installation. 



Check for redundant SQLNet.ora and tnsnames.ora files.



It gets a little ugly when using a single machine for development.


(Developer and the database on a single box.It wasn't really intended to be

that way.)



All in all make sure that both the databse utilities and developer are using
the same client installations.



Below is a note form Oracle for further info...



Good Luck



BRad



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]


<ml2_documents.showDocument?p_id=1068560.6&p_database_id=NOT>.
[NOTE:1016295.4]



<ml2_documents.showDocument?p_id=1016295.4&p_database_id=NOT> and
[NOTE:120498.1] <ml2_documents.showDocument?p_id=120498.1&p_database_id=NOT>
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] <ml2_documents.showDocument?p_id=44694.1&p_database_id=NOT>:
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" 

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Abdul Aleem
  INET: dmit_at_beaconhouse.edu.pk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).


Received on Wed Feb 19 2003 - 00:43:47 CST












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US