That’s a pretty good way of summarising the change. (I wish I’d thought of making the comparison with column updates in tables.)

Very good example.

I want to clarify my undertanding as per your demo below

In 10g bitmap index does not keep histroy of updated bitmap entries (i.e. old values) like B-tree?

Is update to bitmap happens much like update to table?

Please correct if i am wrong

The ideas you’re working through here are exactly the type of cost/benefit analysis everyone should do when they’re thinking about strategic design decisions.

If your most significant problem is the volume of redo generated – and remember that the rate at which you can write the redo is the limit on the speed the database can operate – then you may be prepared to “lose” other resources to address that problem.

I have pointed out that in this scenario you reduce the volume of redo dramatically by using a smaller block size – but also suggested that you might “emulate” this by trying to limit the amount of space used by a larger block size.

Now, setting pctfree to 75 for an 8KB block size is trying to make the blocks behave rather like 2KB blocks – but it probably isn’t going to work all that well in many cases.

Roughly speaking, in the cases where the 75% trick works, the number of blocks you manage for the 2KB and the 8KB approach will be very similar – and the block “management” is largely about latching and list management, not about what goes on inside the blocks – so the resources used for management will be similar.

The 2KB approach is (to my mind) the nicer one because it will always give you small bitmap chunks and will therefore keep the redo as low as possible. The 8KB approach may degenerate to full block usage (and that’s pretty certain to happen in some cases) – so it’s only a temporary solution unless you keep an eye on the index and rebuild it when necessary. On the other hand, having just the 8KB block size does mean you don’t have to manage the 2KB cache – even if you appear to “waste” a lot of memory some of the time.

The block splitting for the 2KB block approach really shouldn’t be a problem – in fact, if you’re going to get block splitting for the 2KB approach it’s almost certainly the case that you shouldn’t use the 8KB with 75% free. When the 2KB blocks split, you only generate just over 4KB of redo … when an 8KB block splits you generate a little over 16KB of redo.

I think this is very very important, especially the start of the paragraph.
Won’t any gain achieved here be negated by the downside of
a) index consuming larger no of blocks and hence more no. of consistent gets (and possibly physical reads) for queries. This is based on assumtion that bitmap index is absolutely essential, which probably means there are other columns in same table that have bitmap indexes on them and queries generally access data by doing ANDs & ORs on these columns.
b) buffer pool having to manage more number of blocks. Not sure if having to manage more no. of small blocks (2KB) has any overhead but having to manage more no. of 8KB blocks sure will have. Right?
c) more occurances of blocks-splitting (especially with 8KB block size and high PCTFREE approach) during updates (or is that not possible?)

Very nicely written blog on bitmap indexes. Gives everyone a nice presentation on what to look for when creating bitmap indexes.

Thanks
Aswath Rao