r12:9fffffffffff1150 r31: 0 ccv: 1
r13:9fffffff7f7cd420 NaTs: 0 unat: 0
r14:7265736f75726365 PRs: cc5b fpsr: 9804c8a74433f
r15:656e71756575655f br0:4000000002835ec0 pfs:c00000000000060f
r16: 2 br1: 0 lc: 0
r17:c0000000919d2800 br2: 0 ec: 0
r18:60000000003ec990 br3: 0 isr: 9fffffff7f801938
r19: 73 br4: 0 ifa: 0
Reason code: 0052
*** 2012-10-12 11:04:11.923
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump[0000000000000000] [SIGSEGV] [Invalid permissions for mapped object][0x000000000] [] []
Current SQL statement for this session:
INSERT INTOSTATS$RESOURCE_LIMIT ( SNAP_ID , DBID , INSTANCE_NUMBER , RESOURCE_NAME ,CURRENT_UTILIZATION , MAX_UTILIZATION , INITIAL_ALLOCATION , LIMIT_VALUE )SELECT :B3 , :B2 , :B1 , RESOURCE_NAME , CURRENT_UTILIZATION , MAX_UTILIZATION, INITIAL_ALLOCATION , LIMIT_VALUE FROM V$RESOURCE_LIMIT WHERE LIMIT_VALUE != 'UNLIMITED' AND MAX_UTILIZATION > 0
----- PL/SQL Call Stack -----
object line object
handle number name
c00000009284ced8 2235 package body PERFSTAT.STATSPACK
c00000009284ced8 91 package body PERFSTAT.STATSPACK
c000000093a2f120 1 anonymous block
在Oracle 9.2.0.6 下的bug 3628622 引起。 当对V$RESOURCE_LIMIT 进行select 和 insert时有2个相关的bug：
Bug 4171822 : SELECT * FROM V$RESOURCE_LIMIT FAILS WITH ORA-07445:
ORA-7445[Qerfxfetch] On Insert Into STATS$RESOURCE_LIMIT [ID 742723.1](bug 3628622)
根据trace 文件中的信息，我们这里的是insert时触发的ORA-7445。所以对应bug：3628622。
该bug不会对数据库产生影响，Oracle 对该bug 并没有提供one-off的patch，所以要解决该bug就必须将数据库升级到更高的版本。 建议升级到11.2.0.3.4.
触发该bug的本质原因在MOS的另一篇文章里有说明：
ORA-7445 Errors on Itanium Platforms due toItanium Symbol Preemption [ID 302172.1]
Cause
Due to Intel's ELF ABI Architecture onItanium Platforms code constructs like:
(*function_pointer)()
i.e. dereferencing a function pointervariable allows for symbol preemption.
On Itanium global variables are adressedindirectly through a global offset process table. The offsets are relative tothe global pointer address (gp).
At runtime due to symbol preemption thefunction pointer address may end up at a location where it cannot be directlyaddressed from the gp value.
This was seen to happen with Oraclefunction pointer variables which were stored in and later reread from the SGA.
As a result the process could not find theexecutable code address and terminated with SIGSEGV.