FATAL ERROR IN TWO-TASK SERVER: error = 12571

[raduiancu]

Hi,
I've got this error 2, 3 times a day, I'm running Oracle 8.1.6 on NT 4.0 SP 6.
The trace file is like this: ORA0021.TRC
Dump file D:\Oracle\admin\hs\udump\ORA00221.TRC
Wed May 15 19:49:52 2002
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows NT Version 4.0 Service Pack 6, CPU type 586
Oracle8i Release 8.1.6.3.0 - Production
JServer Release 8.1.6.3.0 - Production
Windows NT Version 4.0 Service Pack 6, CPU type 586
Instance name: hs

Redo thread mounted by this instance: 1

Oracle process number: 17

Windows thread id: 221, image: ORACLE.EXE


*** 2002-05-15 19:49:52.687
*** SESSION ID:(26.1827) 2002-05-15 19:49:52.312
FATAL ERROR IN TWO-TASK SERVER: error = 12571
*** 2002-05-15 19:49:52.781
ksedmp: internal or fatal error
Current SQL statement for this session:
SELECT UNIQUE
1 UNIONPART,
..........
ORDER BY SERVEDATESTR, ROOMLOCDECODE, UPPERNAME, PATRONID, MEALORDER, RECCATDECODE
*** 2002-05-15 19:50:13.500
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_ksedmp+a8 CALLrel _ksedst+0
50FE4F0
_opitsk+f1c CALLrel _ksedmp+0 2
_opiino+4fd CALLrel _opitsk+0 0
_opiodr+506 CALLreg 00000000 3C 4
450FFBFC
_opidrv+384 CALLrel _opiodr+0 3C 4
450FFBFC
0
_sou2o+19 CALLrel _opidrv+0
_opimai+10c CALLrel _sou2o+0
_OracleThreadStart@4+49f CALLrel _opimai+0 2
450FFE78
77F04EED CALLreg 00000000
----- Argument/Register Address Dump -----
Argument/Register addr=450fe4f0.
Dump of memory from 0x450FE4B0 to 0x450FE5F0
450FE4B0 00000003 00000000 6552210E 00000033 [.........!Re3...]
450FE4C0 00000000 00000003 450FE485 00000000 [...........E....]
..........

Please, if someone could help me!!!
Thanks

[ronnie]

The most common cause for the above error is an ungraceful
disconnection of a session from the oracle db while the db is currently running
a dml statement issued by that session. The error is recorded when oracle
attempts to reply back to the session with the results of the dml and cannot
access the session. Overall database operations are usually not affected.

An ungraceful disconnection could cause by but is not limited to any of the
following:
- the client machine crashed
- the network connection crashed
- the user exited the session improperly (not issuing the 'exit' command)
- the user application allows the user to exit the application without properly
terminating the session.

The above can cause problems with corrupted rollback segments if occurring on a
regular basis and is not addressed. This would require db recovery and
possibly a db rebuild (not a light matter)

PMON will usually rollback most transactions in the rollback segments for a
session if it finds that the session has been ungracefully disconnected, but
there is always a chance that it cannot and this will lead to rollback segment
corruption.



fix:

The dml and the user that issued the dml can be determined from the trace file.
The current dml is in the tracefile header section. The user can be found in
the process state dump of the trace. The process state shows the machine,
o/suser, and user for the session.

The DBA can use this information to determine what the user was doing at the
time and if there was an ungraceful exit from the session the user was
utilizing.

The DBA should then address the cause of the ungraceful exit to reduce the
possibility of reoccurance.

[raduiancu]

thanks a lot for your response