Single table hash clusters

Question

I created a single table hash cluster like this :
create tablespace mssm datafile 'c:\app\mssm01.dbf' size 100m
segment space management manual;
create cluster hash_cluster_4k
( id number(2) )
size 8192 single table hash is id hashkeys 4 tablespace mssm;
-- Created a table in cluster with row size such that only one record fits one block and inserted 5 records each with a distinct key value
CREATE TABLE hash_cluster_tab_8k
( id number(2) ,
txt1 char(2000),
txt2 char(2000),
txt3 char(2000)
CLUSTER hash_cluster_8k( id );
Begin
for i in 1..5 loop
insert into hash_cluster_tab_8k values (i, 'x', 'x', 'x');
end loop;
end;
exec dbms_stats.gather_table_stats(USER, 'HASH_CLUSTER_TAB_8K', CASCADE=>true);
Now, If I try to access record with id = 1 - It shows 2 I/O's (cr = 2) instead of single I/O as is expected in a hash cluster.
Rows Row Source Operation
1 TABLE ACCESS HASH HASH_CLUSTER_TAB_8K (cr=2 pr=0 pw=0 time=0 us)
If I issue the same query after creating unique index on hash_cluster_tab(id), the execution plan shows hash access and single I/O (cr = 1).
Does it mean that to have single I/o in a single table hash cluster, we have to create unique index? Won't it create additional overhead of maintaining an index?
What is the second I/O needed for in case unique index is absent?
I would be extremely thankful if gurus could explain this behaviour .
Thanks in advance ..

Answer 1

>
Now, If I try to access record with id = 1 - It shows 2 I/O's (cr = 2) instead of single I/O as is expected in a hash cluster.
1 TABLE ACCESS HASH HASH_CLUSTER_TAB_8K (cr=2 pr=0 pw=0 time=0 us)
>
As expected? Have you considered that your 'expectation' is wrong?
>
If I issue the same query after creating unique index on hash_cluster_tab(id), the execution plan shows hash access and single I/O (cr = 1).
Does it mean that to have single I/o in a single table hash cluster, we have to create unique index? Won't it create additional overhead of maintaining an index?
What is the second I/O needed for in case unique index is absent?
>
My hypothesis would be that are seeing the effects of having a 'hash collision'; a collision that you caused yourself by the way you defined the table.
Remember when you said this?
>
create cluster hash_cluster_4k
( id number(2) )
size 8192 single table hash is id hashkeys 4 tablespace mssm;
>
You told Oracle there will only be FOUR different IDs used.
And then you said this
>
-- Created a table in cluster with row size such that only one record fits one block and inserted 5 records each with a distinct key value
>
You used FIVE different IDs and only ONE record will fit into each block.
So that record with 'ID=5' is guaranteed to HASH to one of the existing four hash values. And that means you have a 'hash collision'.
The docs explain what happens when you have a 'hash collision'. See the 'Hash Cluster Storage' section in the Database Concepts doc
http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#sthref258
>
Hash Cluster Storage
Oracle Database allocates space for a hash cluster differently from an indexed cluster. In Example 2-9, HASHKEYS specifies the number of departments likely to exist, whereas SIZE specifies the size of the data associated with each department. The database computes a storage space value based on the following formula:
HASHKEYS * SIZE / database_block_size
Thus, if the block size is 4096 bytes in Example 2-9, then the database allocates at least 200 blocks to the hash cluster.
Oracle Database does not limit the number of hash key values that you can insert into the cluster. For example, even though HASHKEYS is 100, nothing prevents you from inserting 200 unique departments in the departments table. However, the efficiency of the hash cluster retrieval diminishes when the number of hash values exceeds the number of hash keys.
>
Using that formula above with HASHKEYS=4, SIZE=8192 and block size=8192 Oracle allocates at least 4 blocks.
The next two paragraphs tell you what happens for a use case like yours: HASH COLLISION
>
To illustrate the retrieval issues, assume that block 100 in Figure 2-7 is completely full with rows for department 20. A user inserts a new department with department_id 43 into the departments table. The number of departments exceeds the HASHKEYS value, so the database hashes department_id 43 to hash value 77, which is the same hash value used for department_id 20. Hashing multiple input values to the same output value is called a hash collision.
When users insert rows into the cluster for department 43, the database cannot store these rows in block 100, which is full. The database links block 100 to a new overflow block, say block 200, and stores the inserted rows in the new block. Both block 100 and 200 are now eligible to store data for either department. As shown in Figure 2-8, a query of either department 20 or 43 now requires two I/Os to retrieve the data: block 100 and its associated block 200. You can solve this problem by re-creating the cluster with a different HASHKEYS value.
>
Note the next to last sentence:
>
As shown in Figure 2-8, a query of either department 20 or 43 now requires two I/Os to retrieve the data: block 100 and its associated block 200.
>
Hmmmm - sounds suspiciously like your use case don't you think?
Try what the doc says in that last sentence and see if it solves your problem:
>
You can solve this problem by re-creating the cluster with a different HASHKEYS value.
>
The parameters you provided and the table example you are using GUARANTEE that if more than FOUR ids are used there will be hash collisions and the result MUST BE what the doc describes. There will NEVER be space in an existing block for a second row so a new block has to be used and that means 'chaining' the blocks to find the one you need: one I/O for each block in the chain.
Jonathan said he could not reproduce your problem but the 'hash' algorithm for his instance might have hashed 'ID=5' to a different value; his 'hash collision' might only occur for ID=2 (or 3 or 4).