这个bug比较奇怪，似乎是由于其他错误而导致了7445错误出现。

后台alert文件中的信息为：

Errors in file /u1/oracle/admin/repdb01/udump/repdb01_ora_23886.trc:
ORA-07445: exception encountered: core dump [000000010073E5D4] [SIGSEGV] [Address not mapped to object] [0x000000018] [] []
ORA-00932: inconsistent datatypes: expected got

对应的TRACE文件中的详细信息为：

bash-2.03$ more /u1/oracle/admin/repdb01/udump/repdb01_ora_23886.trc
/u1/oracle/admin/repdb01/udump/repdb01_ora_23886.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /data/oracle/product/920
System name: SunOS
Node name: newreport
Release: 5.8
Version: Generic_117350-26
Machine: sun4u
Instance name: repdb01
Redo thread mounted by this instance: 1
Oracle process number: 25
Unix process pid: 23886, image: oracle@newreport (TNS V1-V3)

*** 2007-06-23 01:01:39.713
*** SESSION ID:(98.5044) 2007-06-23 01:01:39.676
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x18, PC: [0x10073e5d4, 000000010073E5D4]
*** 2007-06-23 01:01:39.717
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [000000010073E5D4] [SIGSEGV] [Address not mapped to object] [0x000000018] [] []
ORA-00932: inconsistent datatypes: expected got
Current SQL statement for this session:
select dbms_metadata.get_ddl('VIEW','V_3_1','BIDUI') FROM DUAL
----- PL/SQL Call Stack -----
object line object
handle number name
427ae9ca0 0 package body SYS.UTL_XML
42ab71f50 3296 package body SYS.DBMS_METADATA_INT
42ab71f50 4148 package body SYS.DBMS_METADATA_INT
42ab7c2a8 458 package body SYS.DBMS_METADATA
42ab7c2a8 615 package body SYS.DBMS_METADATA
42ab7c2a8 1221 package body SYS.DBMS_METADATA
46eac2458 1 anonymous block
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst()+0 FFFFFFFF7FFF3A60 ?
000000000 ? 000000000 ?
00000003E ?
FFFFFFFF7FFF42F8 ?
1031D56C8 ?
ssexhd()+604 CALL ksedmp()+0 000000000 ? 000103400 ?
0001035D9 ? 000102C00 ?
1035D9000 ? 1035D9C28 ?
sigacthandler()+44 PTR_CALL 0000000000000000 1035E1000 ?
FFFFFFFF7FFF5290 ?
000000000 ? 000000001 ?
1035DEDD8 ? 00000000B ?
qmurdBufOradbOpen() PTR_CALL 0000000000000000 00000000B ?
+500 FFFFFFFF7FFF5290 ?
FFFFFFFF7FFF4FB0 ?
00000000B ? 000000000 ?
FFFFFFFF7FFF54B1 ?
LpxbufPushSource()+ PTR_CALL 0000000000000000 FFFFFFFF7C560870 ?
116 FFFFFFFF7FFF5700 ?
FFFFFFFF7FFF7B00 ?
00000000E ?
FFFFFFFF7FFF54B8 ?
00000000F ?
LpxbufPushURL()+584 CALL LpxbufPushSource()+ FFFFFFFF7C560870 ?
0 FFFFFFFF7C561DF8 ?
FFFFFFFF7FFF5700 ?
FFFFFFFF7C5B0CF0 ?
000000000 ?
FFFFFFFF7C561250 ?

在metalink中仅查询到一条bug信息包含错误函数qmurdBufOradbOpen：Doc ID: Note:2469137.9。

这条记录的描述和当前情况的相似度还是比较高的，首先数据库的版本类似，都是920版本，且7445错误都是由于调用DBMS_METADATA.GET_DDL造成的。而且随后的一些错误函数名称都是一致的。

最大的不同在于，伴随7445错误出现的其他错误信息不同。当前环境下出现的错误是ORA-932：不一致的数据类型。而metalink文章中的错误是ORA-3237。

根据文档的描述和个人的推测，这种问题是在DBMS_METADATA.GET_DDL执行过程中引发的错误造成的不过Oracle在处理异常的时候有些小bug，从而引发了7445错误。

根据metalink的描述，这个问题在10g中解决。这个错误很难重现，而且对系统的影响不大。