ORA-07445 opidsa

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.3 to 10.2.0.3
Information in this document applies to any platform.

Description

After having applied the 10.2.0.3 patch set on any platform, processes from user sessions can core dump (ORA-7445) in opidsa().
The problem is also known to affect 10.2.0.2, but only for Windows platforms when running with 10.2.0.2 Patch 6 upwards.

Likelihood of Occurrence

The problem will typically be seen after the database has been running for some time (weeks). 

Possible Symptoms

The core dump is shown in the alert.log as messages similar to:

ORA-07445: exception encountered: core dump [opidsa()+480] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []

or

ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_opidsa+360] [PC:0x2080540] [ADDR:0x0] [UNABLE_TO_READ] []

Looking at the call stack in the trace file shows:

...
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
 ksedmp()+744         CALL     ksedst()             000000840 ? 1066C42AC ?
                                                   000000000 ? 1066C0DA0 ?
                                                   1066BFB08 ? 1066C0508 ?
 ssexhd()+1240        CALL     ksedmp()             000106400 ? 10652CE64 ?
                                                   10652C000 ? 00010652C ?
                                                   000106400 ? 10652CE64 ?
 sigacthandler()+44   PTR_CALL 0000000000000000     10652A000 ? 1066C7EF0 ?
                                                   106526E2C ? 00010652A ?
                                                   00000000B ? 000000067 ?
 opidsa()+480         PTR_CALL 0000000000000000     00000000B ? 1066C7EF0 ?
                                                   1066C7C10 ? 000000001 ?
                                                   000000000 ? 000010000 ?
 ...

The offset (480 in the example) may vary.

We may have different code paths leading to the opidsa() call, such as:
... opidsa opiodr ttcpip opitsk opiino opiodr opirip opidrv ...
... opidsa kpodny opikpr opiodr rpidrus skgmstack ...

Note that it is also possible for this issue to be seen as a dump in opidsc().

Workaround or Resolution

No real workaround exists for the problem, but flushing the shared pool after receiving the error may clear the situation to prevent further occurrences for a while. Restarting the instance will also clear the problem for a period. Implementing regular flushes of the shared pool can prevent the problem from occurring (this could eg. be executed via DBMS_JOB outside business hours to minimize the impact).

The problem is fixed in 11g via non-published bug:5648872 and the fix is included in 10.2.0.4.