Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 10 ■ DATABASE TABLES 385
the cluster at a time (you have to DROP the existing table in a single table hash cluster before
you can create another). Additionally, if there is a one-to-one mapping between hash keys and
data rows, the access to the rows is somewhat faster as well. These hash clusters are designed
for those occasions when you want to access a table by primary key and do not care to cluster
other tables with it. If you need fast access to an employee record by EMPNO, a single table hash
cluster might be called for. I did the preceding test on a single table hash cluster as well and
found the performance to be even better than just a hash cluster. You could even go a step further
with this example, however, and take advantage of the fact that Oracle will allow you to
write your own specialized hash function (instead of using the default one provided by Oracle).
You are limited to using only the columns available in the table, and you may use only the
Oracle built-in functions (e.g., no PL/SQL code) when writing these hash functions. By taking
advantage of the fact that OBJECT_ID is a number between 1 and 75,000 in the preceding example,
I made my “hash function” simply be the OBJECT_ID column itself. In this fashion, I am
guaranteed to never have a hash collision. Putting it all together, I’ll create a single table hash
cluster with my own hash function via
ops$tkyte@ORA10GR1> create cluster hash_cluster
2 ( hash_key number(10) )
3 hashkeys 75000
4 size 150
5 single table
6 hash is HASH_KEY
7 /
Cluster created.
I’ve simply added the key words SINGLE TABLE to make it a single table hash cluster. My
HASH IS function is simply the HASH_KEY cluster key in this case. This is a SQL function, so I
could have used trunc(mod(hash_key/324+278,555)/abs(hash_key+1)) if I wanted (not that
this is a good hash function—it just demonstrates that we can use a complex function there if
we wish). I used a NUMBER(10) instead of just a number. Since the hash value must be an integer,
it cannot have any fractional components. Then, I create the table in that cluster
ops$tkyte@ORA10GR1> create table t_hashed
2 cluster hash_cluster(object_id)
3 as
4 select OWNER, OBJECT_NAME, SUBOBJECT_NAME,
5 cast( OBJECT_ID as number(10) ) object_id,
6 DATA_OBJECT_ID, OBJECT_TYPE, CREATED,
7 LAST_DDL_TIME, TIMESTAMP, STATUS, TEMPORARY,
8 GENERATED, SECONDARY
9 from all_objects
10 /
Table created.
to build the hashed table. Note the use of the CAST built-in function to make the datatype of
OBJECT_ID be what it must be. I ran the test as before (three runs of each block), and this time
the runstats output was consistently even more positive: