If that is the case then you need to identify the objects that are suffering from the problem and work out if there is a viable way to improve the packing of the blocks without disrupting the clustering of the data.

Note that the sparsely populated blocks may be ones that stay in memory (causing a memory shortage for other data blocks that results in excess I/O on other objects), or they may be blocks that are constantly recycled through memory. A check for popular objects subject to a large amount of I/O may give you clues about the latter – the former may only be identifiable through knowledge of the data and application: in both cases checking row_length x row_count compared to block allocation may give you some idea of space wastage.

Nice article.

I would like to understand the performance impact of having sparsely populated blocks. How can we recognise that our database is suffering from poor performance because of Sparsely Populated Blocks? What will be impact if we’re using Locally Managed Tablespaces?

Thanks in Advance.

Regards,
Santosh Kumar

If your system performance depends on the data being clustered and you don’t realise this then you haven’t designed your system, you’ve just let it happen – and that’s asking for trouble.

If your system is designed to meet the requirements of the users, and that design is dependent on clustering the data in a certain way then that aspect of the design should be recognised, declared and the costs and benefits analysed properly.

If the requirements change so much that a deliberately specified data clustering strategy becomes a liability then you’re right it can be hard work to re-engineer – but that’s not a good excuse for doing it wrong in the first place.

The logical extreme of the concern you have voiced is the approach which says: “Let’s build a really bad system now so that we can change it any way we like later on.” (I’d like to think that this is a rare occurrence, but experience tells me it’s not – although I doubt if the designers expressed their intention the way I just did.)

The “shrink space” option for “alter table” is worth mentioning – but my final remark applies to that feature, too: “you may find that you don’t always want to re-use that space because using it can introduce a different kind of problem.”

Apart from the volume of undo and redo generated, and the impact that shrinking can have on the indexes on the table, the “shrink space” option changes the data pattern quite significantly. If you were depending on the data cluster pattern matching the time of arrival, the row movement can erode the pattern in a similar (though nastier) fashion to the way that my example of setting a high value for pctused causes an increased data spread.

I included a footnote about the OLTP compression mechanism in http://jonathanlewis.wordpress.com/2010/03/30/heap-block-compress/ – the only way that compression could recover blocks on a delete would be by combining the data from multiple blocks, and then “moving” blocks around the table – and that would create havoc with rowids.