FATAL ERROR IN TWO-TASK SERVER: error = 12571

  这个问题貌似是因为应用程序和数据库在连接的时候出现各种意外，如网络不通，丢包，导致连接释放不正常，然后又建立了新的连接的时候报这个错误，不过不影响大局。在实际的观察中，alert_sid.log文件中可以看到这个报错，但是不是持续的报，时间过上一段时间后，就会消失。各位网络上的达人也给出了各种方法。贴出来，一块共享（E文的），个人认为，这个问题没必要解决，DBA啊，但是开发人员应该关注，至少是在处理线程释放的时候，应该有问题。开发不太懂，说的不对的地方，请指出，我会虚心学习的。
   Subject: FATAL ERROR IN TWO-TASK SERVER: error = 12571

RDBMS Version:: 8.1.6
Operating System and Version:: WIN NT 4.0
Error Number (if applicable):: 12571
Server Net Version:: Net8
Client Operating System and Version:: NT4.0
Client Net Version:: Net8, JDBC Thin Driver 2.2

FATAL ERROR IN TWO-TASK SERVER: error = 12571

We are getting FATAL ERROR IN TWO-TASK SERVER: error = 12571
Oracle process number: 11
Windows thread id: 109, image: ORACLE.EXE
FATAL ERROR IN TWO-TASK SERVER: error = 12571
ksedmp: internal or fatal error
Current SQL statement for this session:
UPDATE TBL_REQUEST_WORKFLOW SET V_SEND_TO_ID = 'PR02', V_SEND_TO_ROLE = 'PR', D_MODIFIED_DATE = SYSDATE, V_MODIFIED_BY_USER_ID = 'NU01' WHERE V_REQUEST_ID = '5'
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)

_ksedmp+a8 CALLrel _ksedst+0
1CE4F4
_opitsk+f6b CALLrel _ksedmp+0 2
_opiino+4eb CALLrel _opitsk+0 0
_opiodr+504 CALLreg 00000000 3C 4
31CFBFC
_opidrv+384 CALLrel _opiodr+0 3C 4
31CFBFC
0
_sou2o+19 CALLrel _opidrv+0
_opimai+10c CALLrel _sou2o+0
_OracleThreadStart@4+49f CALLrel _opimai+0 2
31CFE78
77F04EE5 CALLreg 00000000
----- Argument/Register Address Dump -----
Argument/Register addr=31ce4f4.
Dump of memory from 0x31CE4B4 to 0x31CE5F4
Argument/Register addr=31cfbfc.
Dump of memory from 0x31CFBBC to 0x31CFCFC
Repeat 2 times

Repeat 2 times
Argument/Register addr=31cfe78.
Dump of memory from 0x31CFE38 to 0x31CFF78








--------------------------------------------------------------------------------

From: Jamaree Valeriano 13-Mar-01 20:25
Subject: Re : FATAL ERROR IN TWO-TASK SERVER: error = 12571


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.