Fatal error in Two-task server
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 5 of 5

Thread: Fatal error in Two-task server

  1. #1
    Join Date
    Nov 2001
    Location
    denver
    Posts
    11

    Question

    I am recieving an error in the trace files that states the following:

    Redo thread mounted by this instance: 1

    Oracle process number:16
    Windows thread id: 322, image: Oracle.Exe

    Fatal error in two-task server:error = 12571
    ksedmp: internal or fatal error
    Current SQL statement for this session:
    BEGIN courts.InsereProduit( :v1 , :v2 , :v3 , :v4 , :v5 , :v6); END;

    There isn't any error message in the alert log and this only shows up in the trace file. The database version is 8.1.6 qand the platform is NT. Any suggestions? Has anyone seen this error before?

  2. #2
    Join Date
    May 2000
    Location
    Portsmouth, NH, USA
    Posts
    378

    Question


    my question would be:
    How can you get a trace-file without it being in the alert log?
    I thought the alert-log creates or begins the trace file??

    Or am i getting mixed up here?

  3. #3
    Join Date
    Nov 2001
    Location
    denver
    Posts
    11
    That is my thought exactly. I expected to see the error or action within the alert log that generated the trace file but this ins't the case. I see nothing in the alert log around the time the trace file was generated. Any ideas?

  4. #4
    Join Date
    Oct 2000
    Location
    Saskatoon, SK, Canada
    Posts
    3,925
    Here is an extract from metalink forum suggestion:


    Here are some detailed tuning measures that should help:

    The ora-12571 usually indicates an instability between Oracle and the network. Try performing the following to eliminate the error:

    - Shutdown the database
    - Stop the listener
    - Remove all the *.dat files in the c:\orant\otrace80\admin directory
    - Specify the parameter HASH_JOIN_ENABLED = FALSE in the file
    INIT(sid).ORA file
    - Specify the parameter EPC_DISABLED =TRUE in the registry
    (REGEDT32 -> HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE)
    - Restart the database
    - Specify the parameter TCP_KEEPALIVE in the Windows NT registry

    HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters

    Edit - Add value : KeepAliveTime (REG_DWORD)

    Decimal -> 180000 (for example = 3 minutes)

    - Edit the file listener.ora. Configure the parameter
    TRACE_LEVEL_LISTENER = OFF

    - Remove unused protocol addresses, like Named Pipes and SPX, from the LISTENER.ORA file - Start the listener
    - Specify the SQLNET.EXPIRE_TIME = 0 parameter in the sqlnet.ora file

    - Monitor your network


    This can also be a result of a client machine abnormally disconnecting (such as a PC rebooting while a query is running), the server process tries to communicate with the client, the client is no longer there, thus the error is generated.

    This error can also be caused by a client issuing a CTRL-C while query results are being returned.

    This error i sometimes caused by poorly written applications that do not wait for all data to be returned before continuing. The server tries to send data to the client, but the client is not waiting for data.

    The listener may be timing out. Go to the listener.ora file to see what the CONNECT_TIMEOUT_ parameter is set to. Try increasing this in
    increments of 5 (10 to 15). Once the parameter is changed, stop and restart the listener.

    It is important to note that the 'LISTENER' part of this parameter is really the listener name, and is not a static part of the parameter name.

    There should be one CONNECT_TIMEOUT_ for each and every listener defined in the listener.ora file. A default value of 10 seconds will be used if one is not specified in CONNECT_TIMEOUT_ parameter.

    Also, checking the listener.log may provide more detailed error messages.
    -sam
    Thanx
    Sam



    Life is a journey, not a destination!


  5. #5
    Join Date
    Nov 2001
    Location
    denver
    Posts
    11
    I checked the listener.log. The only new information it provided is that there was a service update about the same time the trace file was generated. I will also try the suggestions provided earlier to see if those help.
    Thanks

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