oracle提示ORA-00600 [ddfnetCFull-4], [Invalid Handle]...问题

环境11.2.0.3.7 RAC ON HPUX-IA 11.31, 当使用shared public database link时遇到了BUG. 仅此记录

# DB ALERT LOG

Tue Jun 28 09:09:21 2016
Thread 1 advanced to log sequence 86806 (LGWR switch)
  Current log# 4 seq# 86806 mem# 0: /dev/yyd_oravg02/ryyd_redo04
Tue Jun 28 09:09:26 2016
Archived Log entry 134948 added for thread 1 sequence 86805 ID 0x47ccb6a dest 1:
Tue Jun 28 09:10:53 2016
Global Enqueue Services Deadlock detected. More info in file
 /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_lmd0_3393.trc.
Tue Jun 28 09:13:25 2016
Errors in file /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_ora_16511.trc  (incident=1538131):
ORA-00600: internal error code, arguments: [ddfnetCFull-4], [Invalid Handle], [], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/anbob/anbob1/incident/incdir_1538131/anbob1_ora_16511_i1538131.trc
Tue Jun 28 09:13:28 2016
Dumping diagnostic data in directory=[cdmp_20160628091328], requested by (instance=1, osid=16511), summary=[incident=1538131].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Tue Jun 28 09:13:28 2016
Sweep [inc][1538131]: completed
Sweep [inc2][1538131]: completed
Tue Jun 28 09:14:01 2016
Thread 1 advanced to log sequence 86807 (LGWR switch)
  Current log# 5 seq# 86807 mem# 0: /dev/yyd_oravg02/ryyd_redo05
Tue Jun 28 09:14:06 2016

# Dump file /oracle/app/oracle/diag/rdbms/anbob/anbob1/incident/incdir_1538131/anbob1_ora_16511_i1538131.trc

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle/app/oracle/product/11.2.0.3/dbhome_1
System name:    HP-UX
Node name:      qdyyd1
Release:        B.11.31
Version:        U
Machine:        ia64
Instance name: anbob1
Redo thread mounted by this instance: 1
Oracle process number: 254
Unix process pid: 16511, image: oracle@qdyyd1

*** 2016-06-28 09:13:25.930
*** SESSION ID:(17494.14301) 2016-06-28 09:13:25.930
*** CLIENT ID:() 2016-06-28 09:13:25.930
*** SERVICE NAME:(SYS$USERS) 2016-06-28 09:13:25.930
*** MODULE NAME:(PL/SQL Developer) 2016-06-28 09:13:25.930
*** ACTION NAME:(SQL Window - New) 2016-06-28 09:13:25.930

Dump continued from file: /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_ora_16511.trc
ORA-00600: internal error code, arguments: [ddfnetCFull-4], [Invalid Handle], [], [], [], [], [], [], [], [], [], []

========= Dump for incident 1538131 (ORA 600 [ddfnetCFull-4]) ========

*** 2016-06-28 09:13:25.932
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=0wjqfgz9dqsjp) -----
select null from srp.interface_comm@srp1   
 where rowid = :plsqldev_rowid
 for update nowait
 
...
ub4 koktatu_p [9FFFFFFF7F3BDB78, 9FFFFFFF7F3BDB7C) = 00000000
ub4 ugafl_p [9FFFFFFF7F3BDB7C, 9FFFFFFF7F3BDB80) = 00000000
struct ncodef ** uganc_p [9FFFFFFF7F3BDB80, 9FFFFFFF7F3BDB88) = 9FFFFFFF ...
Dump of memory from 0x9FFFFFFF7F3BDB84 to 0x9FFFFFFF7F3BDB88
9FFFFFFF7F3BDB80          7F3F6D88                        [.?m.]
        NCONAM = 'SRP1.HEBEI.MOBILE.COM'
        NCOUID = 592
        NCOFLG = 12930
        NCO2PSTR = 1
        HSTPRO = 6
        HSTFLG = 1073753505
Dump of memory from 0x9FFFFFFF7F3F6D88 to 0x9FFFFFFF7F3F6DC8

...
 

Error Descriptor: ORA-600 [ddfnetCFull-4] [Invalid Handle] [] [] [] [] [] [] [] [] [] []
Error class: 0
Problem Key # of args: 1
Number of actions: 13
----- Incident Context Dump -----
Address: 0x9ffffffffffeaba0
Incident ID: 1538131
Problem Key: ORA 600 [ddfnetCFull-4]
Error: ORA-600 [ddfnetCFull-4] [Invalid Handle] [] [] [] [] [] [] [] [] [] []
[00]: dbgexProcessError [diag_dde]
[01]: dbgeExecuteForError [diag_dde]
[02]: dbgePostErrorKGE [diag_dde]
[03]: dbkePostKGE_kgsf [rdbms_dde]
[04]: kgeadse []
[05]: kgerinv_internal []
[06]: kgerinv []
[07]: kgesinv []
[08]: ksesin [KSE]
[09]: OCIKSIN []
# GET dblink DDL

SQL> select dbms_metadata.get_ddl('DB_LINK','SRP1','PUBLIC') from dual;

DBMS_METADATA.GET_DDL('DB_LINK','SRP1','PUBLIC')
---------------------------------------------------------------------------------------------------

  CREATE SHARED PUBLIC DATABASE LINK "SRP1"
   CONNECT TO "SRP" IDENTIFIED BY VALUES 'xxxxxxxxxxxxxxxxxxxxxx'
   AUTHENTICATED BY "SRP" IDENTIFIED BY VALUES 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
   USING 'ng1_weejar_a1';
根据MOS NOTE 1380017.1 记录属于在当前版本下使用shared public dblink时触发， 应属于bug 12977043

Typically this will happen when using shared, public database links,
however any other configuration that could result in an ORA-23 being
raised at the remote site could be a case of this bug.

To confirm that this is the case, search for the string “struct ncodef ** uganc_p”
in the trace file and identify the NCOFLG value. If the bits 0x0200 (NCODBCONC)
and 0x1000 (NCOSESSTICKY) are set, then this is the right bug.

Example:

From the trace file we search for “struct ncodef ** uganc_p” and find
the following:

struct ncodef ** uganc_p [021FDD638, 021FDD640) = 224D7888 00000000
NCONAM = ‘IMSVCSLNK.WORLD’
NCOUID = 45
NCOFLG = 12930
NCO2PSTR = 1
HSTPRO = 6
HSTFLG = 1073753505

The value of NCOFLG is 12930 = 0x3282 and since we have both the
0x0200 and the 0x1000 bits set, this confirms the duplicate.

Solution
Use a Public database link instead of a Shared database link
OR
This issue is fixed in:
12.2 (Future Release)
11.2.0.4 (Future Patch Set)
11.2.0.3 Patch 17 on Windows Platforms