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

CHAPTER 10 ■ DATABASE TABLES 389
Creating a sorted hash cluster is much the same as the other clusters. To set up a sorted
hash cluster capable of storing the above data, we could use the following:
ops$tkyte@ORA10G> CREATE CLUSTER shc
2 (
3 cust_id NUMBER,
4 order_dt timestamp SORT
5 )
6 HASHKEYS 10000
7 HASH IS cust_id
8 SIZE 8192
9 /
Cluster created.
We’ve introduced a new keyword here: SORT. When we created the cluster, we identified
the HASH IS CUST_ID and we added an ORDER_DT of type timestamp with the keyword SORT.
This means the data will be located by CUST_ID (where CUST_ID=:X) and physically retrieved
and sorted by ORDER_DT. Technically, it really means we’ll store some data that will be retrieved
via a NUMBER column and sorted by the TIMESTAMP. The column names here are not relevant, as
they were not in the B*Tree or HASH clusters, but convention would have us name them after
what they represent.
The CREATE TABLE for our CUST_ORDERS would look like this:
ops$tkyte@ORA10G> CREATE TABLE cust_orders
2 ( cust_id number,
3 order_dt timestamp SORT,
4 order_number number,
5 username varchar2(30),
6 ship_addr number,
7 bill_addr number,
8 invoice_num number
9 )
10 CLUSTER shc ( cust_id, order_dt )
11 /
Table created.
We’ve mapped the CUST_ID column of this table to the hash key for the sorted hash cluster
and the ORDER_DT column to the SORT column. We can observe using AUTOTRACE in SQL*Plus
that the normal sort operations we expect are missing when accessing the sorted hash cluster:
ops$tkyte@ORA10G> set autotrace traceonly explain
ops$tkyte@ORA10G> variable x number
ops$tkyte@ORA10G> select cust_id, order_dt, order_number
2 from cust_orders
3 where cust_id = :x
4 order by order_dt;