FATAL ERROR IN TWO-TASK SERVER: error = 12152

           今天早上發現在 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: (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:

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

 

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.

References