1.Can you please explain why you have recommended to hash on the first column only.
I wasn’t thinking in a sufficiently general way – my thoughts were focused too much on the case of the sequence based key with a high rate of insert. The hashing has to be on the leading columns of a globally partitioned index (i.e. global partitioned indexes have to be prefixed), but doesn’t have to be restricted to just the first column.

2.Is this hashing only helpful during concurrent inserts “by spreading across blocks”? What is the impact during retrieval?
I think that you’ll find that that point is addressed in the third paragraph of the section. depending on the nature of the predicates it can introduce extra work on the retrieval.

3. Consider this, I have a column with low cardinality. Will not adding a column (primary-key) in the hash function reduce hash-collisions and spreading?

That’s a point worth raising, but there are a couple of different scenarios to consider, for example:

If you have periods of time where the high concurrency is all about just one distinct value, then hashing on that column is clearly NOT going to spread the load – so you have to have at least a second column in the index with a large number of distinct values and a two-column hash to spread the load; but then your queries have to be “where col1 = constant and col2 = constant” if you want them to be efficient. Of course, you might consider creating the index with the less repetitive column first, hashing on just that column because then you could use the index efficiently for queries that involved both columns or just the less repetitive column.

If your periods of high concurrency use several of your “low cardinality” values then it’s possible that that is, of itself, sufficient to spread the load across a number of different insertion points, making the partitioning unnecessary.

In passing, if your “low cardinality” column is the leading column of an index it’s worth looking at compressing the index on that column.

1.Can you please explain why you have recommended to hash
on the first column only.

2.Is this hashing only helpful during concurrent inserts
“by spreading across blocks”? What is the impact during
retrieval?

3. Consider this, I have a column with low cardinality.
Will not adding a column (primary-key) in the hash
function reduce hash-collisions and spreading?

It sounds as if you’ve been dropping partitions with the “update (global) indexes” option.

Nice to hear that the coalesce is a more appropriate solution.

You may still need to do one more rebuild, though, if you’ve allowed a history of drops to accumulate, as you may now have N partitions worth of empty space on your index freelists when perhaps you want to get that down to a steady state of just one partition’s worth of space.

It’s typical of sorting out indexing problems – once you’ve figured out the correct strategy, you sometimes have to do just one more rebuild (with the correct configuration) before you can tick all the boxes.

The reason for considering the partition strategy is two-fold – first you hope that after partitioning the index once you don’t have to rebuild; and second even if you never see the ITL problem, there are indexes of this type that see buffer busy waits and other contention and partitioning can deal with those waits. But as I said, it is important to consider how you’re going to use the index in queries or you may lose more than you gain.

So I had the usage wrong, I was using ora_hash(id,8) for 8 partitions instead of ora_hash(id,7). Just tested it out, seems to work for both strings and numbers!

I’ll review that chapter again. In the case of an index however, wouldn’t it be easier to rebuild it, rather than re-partition? Not that I don’t like power of 2, just trying to understand the logic behind it. To avoid having rules of thumb without knowing where the “thumb” comes from :)

This was a topic I covered in “Practical Oracle 8i” Chapter 12. The “power of 2″ implementation makes it relatively painless to increase or decrease the number of partitions in a hash-partitioned table as you don’t have to redistribute all the data in the table, only the data of one (to split) or two (to merge) partitions.

When I wrote the book, 8i had a packaged procedure dbms_utility.get_hash_value() that could be used to return the hash partition position for a string value; but things may have changed since then. The ora_hash() function returns the internal partition if used correctly.

Example: ora_hash(38454,7) will return the internal partition number (0 to 7, rather than 1 to 8 ) of the hash partition that should hold the value 38454 if you have created a table with eight hash partitions.