Index Rebuild ?

While searching on Metalink for clues about an oddity relating to an index rebuild, I came across Bug 6767655  – reported in 10.2.0.3 and fixed in 11.2.  The problem is described as follows:

When having two sessions running concurrently, one doing inserts to a partitioned table, and the other doing partition maintenance operations, there is a chance of the DML session core dumping in kauxs_do_journal(),  i.e.:

ORA-7445: exception encountered: core dump [kauxs_do_journal()+21] [SIGSEGV]  [Address not mapped to object] [0x2] [] []

DIAGNOSTIC ANALYSIS:
The problem seems to be a timing issue – or at least there is a timing component involved. When doing the partition split, an ORA-54 is normally raised, however by running the split in a loop, it will eventually succeed (and thus causing problems for the session running the DML).

This is an example of the type of report on Metalink that really irritates me. Why ? Because of the lack of consistency in the content. The title of my posting is about rebuilding indexes – but this problem is (apparently) not about rebuilding indexes … until you get into the information about rediscovery and workarounds:

RELEASE NOTES:
While doing concurrent DML and rebuilding indexes online there is chance of core dump in kauxs_journal.

REDISCOVERY INFORMATION:
Dump in kauxs_journal while doing concurrent DML and index rebuild online.

WORKAROUND:
Avoid concurrent DML and index rebuild online. Serialize these operations.

Suddenly all references to partitions and partition maintenance have disappeared and the issue is all about index rebuilds. The only way I can link the two together is  by assuming that the problem first appeared to be related to partiiton splits because someone wrote some code that rebuilt index partitions online immediately after the partition split. But I’d really like to have a clear explanation.

Should I worry when I’m not using partitions at all, or does it apply only to locally partitioned indexes, or maybe partitioned indexes on non-partitioned table, or globally partitioned indexes on partitioned tables, global indexes on partitioned tables – and how significant is that “split” ?

I don’t like having to guess … especially in a case like this where the diagnostic analysis says “there’s a timing component – sometimes it works sometimes it fails”. Is my code working today (or in development) because it’s a lucky day, or is it working because the bug doesn’t appear in my particular case.

[Further reading on rebuilding indexes]