Re: ASSM bug: slow INSERT after uncomitted DELETE

From: ca111026 <ca111026_at_gmail.com>
Date: Sun, 9 Aug 2009 17:11:42 -0700 (PDT)
Message-ID: <23f576d0-f399-4cbb-8c2a-e134c190cfb5_at_l35g2000pra.googlegroups.com>

I tested using Oracle 11.1.0.7.0 (64-bit) on AIX 5.3 - the problem is still there, it has not been fixed.

Now, these bitmaps, shouldn't they be updated in transactionally consistent way like everything else?
Let's say all rows have been deleted from the table, but DELETE hasn't been commited. Another session comes
and attempts to run insert. It checks bitmap for free space in the blocks that have already been allocated to the table. If bitmap is transactionally consistent then it will show that all blocks are full, so instead of trying to insert into existing blocks Oracle will allocate another extent. Do I miss something here? Is there a reason why bitmaps cannot be part of transaction?

Is it a bug or a "feature"? Received on Sun Aug 09 2009 - 19:11:42 CDT