random technical thoughts from the Nominet technical team

Some issues with Oracle 10.2.0.3 patchset

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...
Posted by jason on Mar 16th, 2007

We have recently applied the latest Oracle patchset, 10.2.0.3 to our databases. While installing went smoothly enough the new patchset has not been without issues, here are some of the problems (none of which were evident in 10.2.0.2) we are finding:

ORA-07445: EXCEPTION ENCOUNTERED: CORE DUMP [OPIDSA()+386] [SIGSEGV]

This seems to be being caused by Oracle application express, though apparently is more to do with memory management on the server rather than application specific. There has just recently been a metalink note posted about this: 418855.1

This has a bug number 5648872 and there will be a patch available for this (with the same number as the bug) at some point.

Next up we saw the following in our alert log:

ORA-600 [KCRRUPIRFS.20] [4] [368]

This error was accompanied by the arc process dying (to our standby database) and the following being dumped into a trace file:

Corrupt redo block 479421 detected: bad block number

I can find no hardware issues and we were able to get the redo data to the standby ok. This is still ongoing with oracle.

Final error for this blog posting was an issue with our physical standby after being patched to 10.2.0.3:

ORA-00600: INTERNAL ERROR CODE, ARGUMENTS: [KCRFR_RESIZE2], [652614828032]

This error occurred upon trying to start the managed recovery process

Which it failed to do. This error may be caused by a corrupt archivelog file on the standby, though how this corruption came about is as yet unknown. There is more about 10.2.0.3 and physical standby databases in a future posting.

5 Responses

  1. Jim Scheitel Says:

    We have been experiencing the same messages:
    ORA-07445: exception encountered: core dump [opidsa()+386] [SIGSEGV] [Address not mapped to object] [0×000000000] [] []

    We have four identical production 10gR2 10.2.03 two node 64bit linux RAC clusters, with many Schemas spread out across those clusters, and these errors are only happening on one schema when users are connected to the second node. If they are connected to the first node, they do not experience the problem, if they are connected to another schema on the same cluster, then they do not get any errors. (using the same programs from the same set of citrix application servers!) We have been going round and round with Oracle for days on this trying to figure out what it was.

  2. jason Says:

    A patch has been released for this issue: 5648872 you can grab it from metalink.

    I have not tested this yet.
    By the way are you experiencing this with apex, or is it a different application?

  3. Saravanakumar Says:

    We are also experiencing the same problem:

    ORA-07445: exception encountered: core dump [opidsa()+480] [SIGSEGV] [Address no
    t mapped to object] [0×000000000] [] []

    We have 10g R2 10.2.0.3 on solaris 10 sparc 64 with one schema. This error is caused by TOAD 7.3 attimes. This session gets disconnected for a while and when we try after some time it works fine.

  4. jason Says:

    The patch 5648872 does fix this issue quite nicely. I’d recommend applying it if this issue is causing you some pain, it certainly seems to have cleared up our problems.

  5. techblog » Blog Archive » Oracle support woes Says:

    […] a fix. Mostly these issues have arisen due to us having applied the latest Oracle patchset, 10.2.0.3. Here is a list of our current […]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Recent Posts

Highest Rated

Categories

Archives

Meta: