FATAL ERROR IN TWO-TASK SERVER: error = 12152

最新推荐文章于 2025-12-13 03:06:24 发布

转载最新推荐文章于 2025-12-13 03:06:24 发布 · 297 阅读

本文记录了一次在Linux AS3.0 + Oracle 9.2.0.7 RAC环境中遇到的ORA-12571错误情况。此错误源于客户端异常断开连接导致服务器进程无法正常退出，进而生成了重复的跟踪文件。文中详细介绍了错误日志的内容及Metalink上的官方解释。

今天早上发现在 Linux AS3.0 + Oracle9.2.0.7 RAC （双节点）的节点1上alert log中有频繁的 ora-12571 tns方面的报错，并且有相关trace file生成，而且发现 trc 文件中的内容是一样的。是一个简单的SQL , 对一个 5000多笔数据的Table进行访问(没有条件)。后来查询了一下metalink 发现是一个bug , 原因是客户端died 或不正常退出连接导致Server Process不能发送信息给client，导致了这些个trace的产生，不过需要升级到 9208 ， 10.2.0.1 或更高。近期比较难有机会升级，这个错误如果不是太频繁，不会造成什么大的影响。详细的解释见最后metalink文章。

Alert log :

------------------------------------------------------
Sat Jul 19 03:18:41 2008
ARC1: Evaluating archive log 3 thread 1 sequence 4819
ARC1: Beginning to archive log 3 thread 1 sequence 4819
Creating archive destination LOG_ARCHIVE_DEST_1: '/ocfs_arch1/orcl/1_4819.dbf'
ARC1: Completed archiving log 3 thread 1 sequence 4819
Sat Jul 19 03:22:46 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15181.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:22:55 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15185.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:23:39 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15197.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:23:46 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15201.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:25:25 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15216.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:25:32 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15220.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:25:39 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15224.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 03:25:45 2008
Errors in file /u01/product/admin/orcl/udump/orcl1_ora_15228.trc:
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Sat Jul 19 04:00:00 2008
Thread 1 advanced to log sequence 4821
Current log# 2 seq# 4821 mem# 0: /ocfs_ctrl_redo/orcl/redo02.log
Current log# 2 seq# 4821 mem# 1: /ocfs_data/orcl/redo02b.log
Sat Jul 19 04:00:00 2008
ARC1: Evaluating archive log 4 thread 1 sequence 4820
ARC1: Beginning to archive log 4 thread 1 sequence 4820
Creating archive destination LOG_ARCHIVE_DEST_1: '/ocfs_arch1/orcl/1_4820.dbf'
ARC1: Completed archiving log 4 thread 1 sequence 4820
Sat Jul 19 04:50:53 2008
Thread 1 advanced to log sequence 4822
Current log# 1 seq# 4822 mem# 0: /ocfs_ctrl_redo/orcl/redo01.log
Current log# 1 seq# 4822 mem# 1: /ocfs_data/orcl/redo01b.log

Trace File :

--------------------------------------------------------------------------------------
/u01/product/admin/orcl/udump/orcl1_ora_15197.trc
Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
ORACLE_HOME = /u01/product/oracle
System name:    Linux
Node name:      DELL-RAC01
Release:        2.4.21-37.ELsmp
Version:        #1 SMP Wed Sep 7 13:28:55 EDT 2005
Machine:        i686
Instance name: orcl1
Redo thread mounted by this instance: 1
Oracle process number: 176
Unix process pid: 15197, image: oracle@DELL-RAC01 (TNS V1-V3)

*** 2008-07-19 03:23:39.529
*** SESSION ID:(100.33927) 2008-07-19 03:23:39.529
FATAL ERROR IN TWO-TASK SERVER: error = 12152
*** 2008-07-19 03:23:39.529
ksedmp: internal or fatal error
ORA-12571: TNS:灏佸寘瀵?叆鍣ㄥけ鏁
Current SQL statement for this session:
SELECT R_FEEDER_DESC_T.*, R_FEEDER_DESC_T.ROWID FROM R_FEEDER_DESC_T
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+274         call     ksedst()             0 ? 0 ? 0 ? 0 ? BF00B1CC ?
                                                   95CB201 ?
opitsk()+3953        call     ksedmp()             2 ? A6288B8 ? 2F78 ?
opiino()+1331        call     opitsk()             0 ? 0 ? AEF7D60 ? B1646E8 ?
                                                   F4 ? 0 ?
opiodr()+1135        call     00000000             3C ? 4 ? BFFFCF5C ?
opidrv()+418         call     opiodr()             3C ? 4 ? BFFFCF5C ? 0 ?
sou2o()+30           call     opidrv()             3C ? 4 ? BFFFCF5C ?
main()+187           call     sou2o()              BFFFCF40 ? 3C ? 4 ?
                                                   BFFFCF5C ? 253710 ? 0 ?
__libc_start_main() call     00000000             2 ? BFFFCFC4 ? BFFFCFD0 ?
+170                                               253518 ? 2 ? 8215990 ?

...........

    ----------------------------------------
    SO: 0x99138a88, type: 8, owner: 0x94cd918c, flag: INIT/-/-/0x00
    (FOB) flags=2 fib ptr=9a0aa464 incno=0 pending i/o cnt=0
    ----------------------------------------
    SO: 0x94dd9e38, type: 4, owner: 0x94cd918c, flag: INIT/-/-/0x00
    (session) trans: (nil), creator: 0x94cd918c, flag: (8100041) USR/- -/-/-/-/-/-
              DID: 0001-00B0-00000017, short-term DID: 0000-0000-00000000
              txn branch: (nil)
              oct: 0, prv: 0, sql: (nil), psql: 0xae9fe5fc, user: 52/MPROGRAM
    O/S info: user: F2138303, term: DMD1-ENG-012, ospid: 2112:2156, machine: PCEG\DMD1-ENG-012
              program: Feeder.exe
    application name: Feeder.exe, hash value=0
    last wait for 'SQL*Net break/reset to client' blocking sess=0x0 seq=180 wait_time=1
                driver id=54435000, break?=0, =0
    temporary object counter: 0
      ----------------------------------------

Metalink 的解释：

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

Applies to:

Oracle Net Services - Version: 8.1.7 to 10.1
Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 10.1.0.4.0
This problem can occur on any platform.

Symptoms

Server side trace files with an ORA-12152 similar to the following are generated intermittently:

*** SESSION ID:(23.28259) 2006-02-09 08:09:36.016
FATAL ERROR IN TWO-TASK SERVER: error = 12152
*** 2006-02-09 08:09:36.030
ksedmp: internal or fatal error
Current SQL statement for this session:
...

In the process state of the trace file, something like the following is seen:

    SO: 38db25310, type: 4, owner: 38da1ccf8, flag: INIT/-/-/0x00
    (session) trans: 0, creator: 38da1ccf8, flag: (8000041) USR/- -/-/-/-/-/-
              DID: 0001-0010-0000000E, short-term DID: 0000-0000-00000000
              txn branch: 0
              oct: 0, prv: 0, sql: 0, psql: 392596b58, user: 173/#####
    O/S info: user: #####, term: , ospid: 11711, machine: #####
              program: #####@##### (TNS V1-V3)
    application name: #####@##### (TNS V1-V3), hash value=0
    last wait for 'SQL*Net break/reset to client' blocking sess=0x0 seq=1006 wait_time=-1
                driver id=54435000, break?=1, =0
    temporary object counter: 0

Cause

The client application died (or dropped the connection) before the server process could send the break/reset message back, and that prevented the server process from exiting gracefully. This caused the server trace file to be dumped.

This issue has been reported and fixed via non-published bug:3816595

Solution

Bug:3816595 is fixed in 10.2.0.1, and the fix is included in the 9.2.0.8 and 10.1.0.5 patchsets as well.

Either upgrade to a version where the problem is fixed, or simply ignore the trace files as they are quite harmless.