geotiger
asked on
FATAL ERROR IN TWO-TASK SERVER: error = 12571
The two databases that I inherented have been generating trace files and log the above error. The OS is Window 2000 SP4. The database version is 9.2.0.1. Since it is a production environment, update to a newer version is next to imposible. The following is excerption from one of the trace file. The DB user issue the sql statement is system. It seems this does not fit into the possible causes from this link:
https://www.experts-exchange.com/questions/20822491/Periodical-error-on-running-a-stored-procedure.html
It seems on the server side. I seems most time it happens right after completing a archive log. My questions are
1) how could I find out which process or job issue the sql statement?
2) how could I prevent it from happening?
I contacted Oracle support as well, but their suggestion is to upgrade to version 9.2.0.7. Does this mean there is bug in version 9.2.0.1? Where is the bug doc or fix? If it is a bug, I need to provide to our validation team so that they can approve an upgrade.
Thanks.
GT
---- from alert log -----
Thu Apr 13 02:54:27 2006
ARC0: Evaluating archive log 8 thread 1 sequence 39636
ARC0: Beginning to archive log 8 thread 1 sequence 39636
Creating archive destination LOG_ARCHIVE_DEST_1: 'K:\ORACLE\ORADATA\D01\VP_
ARC0: Completed archiving log 8 thread 1 sequence 39636
Thu Apr 13 03:44:55 2006
Errors in file f:\oracle\admin\vp\udump\v
Thu Apr 13 04:19:55 2006
Errors in file f:\oracle\admin\vp\udump\v
----- from a trace file -----
...
*** 2006-04-13 04:19:55.000
*** SESSION ID:(36.13376) 2006-04-13 04:19:55.000
FATAL ERROR IN TWO-TASK SERVER: error = 12571
*** 2006-04-13 04:19:55.000
ksedmp: internal or fatal error
Current SQL statement for this session:
select /*+ Rule */ sum(f.bytes)/1024, floor(sum(f.bytes)/1024) from sys.dba_free_space f, v$datafile d where f.file_id = d.file# and d.status in ('ONLINE', 'SYSTEM') and tablespace_name = 'SYSTEM' group by tablespace_name
...
ASKER
Yes, I have read it and it is referenced in the link that I posted. The application connecting to the database is Java application running on WebLogic application server. The Java app creates 10 dedicated connections to Oracle database when it starts, then use the 10 connection as a pool. How would Oracle handle the pool if most of the dedicated connections are idles for long time and then suddenly gets very busy?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
After checking Oracle's bug database for version 9.2.0.1, it seems that our case does not fits with anyof the descriptions in the bug database.
Since most of the trace files are generated by dbsnmp.exe (Oracle agent), I stopped unwanted/unused services on Oracle server including Oracle Apache server, Oracle agent, MTSrecoveryService, Distributed Transaction Coordinator services. It seems that Oracle stopped generating the annoying trace files.
We plan to upgrade Oracle to 9.2.0.7 with new Java application release.
GT
ASKER
This is just an update. I have not seen the error message nor the trace files since I turned off those services.
Thanks.
GT
I insist in that 9.2.0.1 is too bugy
and it is risky to use it.
Even 9.2.0.7 has bugs.
Good luck!
and it is risky to use it.
Even 9.2.0.7 has bugs.
Good luck!
ASKER
I agree.
GT
cause: 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 recurrence.