DBAsupport.com Forums - Powered by vBulletin
Results 1 to 3 of 3


  1. #1
    Join Date
    Oct 2001


    My company has recently been deserted by the tech folks managing our
    systems, including the Oracle 8i db, which is the back-end to our
    website. Here's our platform:

    Compaq Proliant 3000
    OS:NT 4.0, OP 6
    Cold Fusion Server 4.0
    Oracle 8i - ver. 8.1.5

    Our website was running flawlessly until the following changes were
    made -

    Upgraded to service pack 6
    Installed NIMDA virus patch (from Microsoft)
    Updated Compaq controllers and bios (recommended by Compaq)

    After all was installed, we now experience the following symptoms from

    - The database, which normally starts up almost instantly, is taking
    approx 8 minutes to get going
    - After up and running without issue for approx 5-10 minutes, the db
    shuts down with the following error message: ORA-12571:TNS:PACKET
    WRITER FAILURE. When the db is up, there is no connectivity problem
    with cold fusion server, the site runs as it were normal.

    I am in the unfortunate position of having to manage this issue with
    no experience, so any help or suggestions would be EXTREMELY


  2. #2
    Join Date
    Oct 2000
    Saskatoon, SK, Canada
    Curtesy to Oracle Metalink:


    Give an overview of what to adjust and verify in case of ORA-12151
    and ORA-12571 errors


    This notes applies to all who are facing intermittent SQL*Net read and
    write errors while working on NT.


    ORA-12151 and ORA-12571 errors on Windows NT

    Intermittent SQL*Net TCP/IP read and write errors are sometimes encountered
    on NT. The underlying reasons of these errors are a synchronization error
    in the TCP/IP layer on NT. To help prevent this kind of errors, a
    few things can be adjusted to help the synchronization:

    1. TCP.NODELAY parameter
    This parameter is to be added in the "PROTOCOL.ORA" file in the
    "NETWORK\\ADMIN" directory.

    In most cases, TCP/IP info send across the network is buffered
    till 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 info can be send as well.
    This has the potential to generate timeouts and errors.
    To avoid this, this delay can be switched off.

    tcp.nodelay = yes

    2. Disabling AUTOMATIC_IPC on Clients
    On client PC's, checking for IPC connections is pointless as there
    is never a database installed on them. So, in order to save some
    time during the connections phase, set AUTOMATIC_IPC=OFF in the
    "SQLNET.ORA" file.

    3. "NAMES.DIRECTORY_PATH" to force using "TNSNAMES.ORA" or "ONAMES"
    If you have a fixed environment, it's best to specify this in the
    "SQLNET.ORA" file. The parameter "NAMES.DIRECTORY_PATH" specifies how
    the TNS resolving takes 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,
    and will afterwards start checking for a "TNSNAMES.ORA" file.

    If you have only a "TNSNAMES.ORA" file, and no Oracle Names installed,
    it is best to specify this parameter to skip the Names searching in
    order to speed up the TNS resolving time.

    The value of this parameter is a comma separated list, with as
    possible values TNSNAMES (for "TNSNAMES.ORA" searching) and "ONAMES"
    (for Oracle Names searching).

    4. TCP/IP timeouts on NT
    The default retransmission count on 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.
    In the registry, change the following value:

    TcpMaxDataRetransmissions REG_DWORD "number"

    This parameter is not present in the registry by default. This
    means that the first time, this parameter will need to added to
    this registry key.

    This parameter can be useful on both client and server. Suggested
    course of action is to first add this parameter on the machine
    generating the SQL*Net errors, and if the problem persists, also
    include the parameter in the registry of the other machine.

    5. TCP/IP keepalive on NT
    KEEPALIVE is an extension to TCP/IP which enables the closing of
    dead connections which are no longer being used.

    Problems can occur when the server does not close a connection
    after a PC client process has disappeared. This typically happens
    when a PC user switches off or reboots their machine while still
    connected to Oracle. Note that this is not an Oracle problem, but
    a limitation of TCP/IP, which has no way of knowing for sure
    whether a remote connection has disappeared.

    This feature is enabled by default on NT. Problem can occur however
    if the timeout period is too fast for some heavily used or slow
    network. In those conditions, the KEEPALIVE registry value can be
    used to specify a KEEPALIVE value before a connection gets cut.

    KeepAlive REG_DWORD "number"

    A value of '10' is a common value specified for this variable.

    Again, this parameter can be useful on both client and server.
    Start with the machine generating the error, and if needed, also add
    it on the machine on the other side.

    6. TCP/IP timeouts on Windows 95
    The same parameter can also be specified on Windows 95. It has the
    same functionality, only the location of the parameter in the
    registry is different.

    TcpMaxDataRetransmissions REG_DWORD "number"

    This parameter is not present in the registry by default. This
    means that the first time, this parameter will need to added to
    this registry key.

    The purpose and behavior of the parameter is the same on the Windows 95
    and Windows 98, as on the Windows NT platform.

    7. SDU & TDU parameters
    Part of this problem is the sequence of information that gets transmitted.
    If there are disruptions in the sequence, the errors ORA-12151 and
    ORA-12571 can also appear, alerting the application that not all information
    has been send 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 packet split-ups will have to be made.

    By default, SQL*Net is using an SDU (Session Data Unit) of 2048 bytes (2Kb)
    and a TDU (Transport Data Unit) of 32768 (32Kb) bytes.
    On standard Ethernet connections, with no special modifications made, the
    SDU is 1500 bytes, while the TDU is 8760 bytes.

    With these values, each data request made by SQL*Net will have to be split
    up in several smaller packets to actually be able to transmit.

    Therefore, to minize the creation the additional packets, it is advised, in
    case of these errors, to synchronize the SDU and TDU parameters at the
    SQL*Net level with those of the actual network topology used.

    These SDU and TDU parameters have to be specified at both the client and
    the server configuration files:

    (ADDRESS =(PROTOCOL=TCP)(Host=foobar)(Port=1521))
    (SID = ORCL)

    (SID_LIST =
    (SID_DESC =
    (SDU = 1500)
    (TDU = 8760)

    For more information about the SDU and TDU parameter, see Note 44694.1,
    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 NT, via the TcpWindowSize parameter:

    TcpWindowSize REG_DWORD "number"


    Life is a journey, not a destination!

  3. #3
    Join Date
    May 2000
    If the problem persists, then use Network Cable Analyzer to check for the obstruction of cables.
    This equipment sends signal at regular interval and echos back.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Click Here to Expand Forum to Full Width