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

CHAPTER 10 ■ DATABASE TABLES 371
different PCTFREEs would not make sense. Therefore, a CREATE CLUSTER looks a lot like a
CREATE TABLE with a small number of columns (just the cluster key columns):
ops$tkyte@ORA10GR1> create cluster emp_dept_cluster
2 ( deptno number(2) )
3 size 1024
4 /
Cluster created.
Here, we have created an index cluster (the other type being a hash cluster, which we’ll
look at in the next section). The clustering column for this cluster will be the DEPTNO column.
The columns in the tables do not have to be called DEPTNO, but they must be NUMBER(2), to
match this definition. We have, on the cluster definition, a SIZE 1024 option. This is used to
tell Oracle that we expect about 1,024 bytes of data to be associated with each cluster key
value. Oracle will use that to compute the maximum number of cluster keys that could fit
per block. Given that we have an 8KB blocksize, Oracle will fit up to seven cluster keys (but
maybe fewer if the data is larger than expected) per database block. This is, the data for
departments 10, 20, 30, 40, 50, 60, and 70 would tend to go onto one block, and as soon as we
insert department 80, a new block will be used. That does not mean that the data is stored in a
sorted manner; it just means that if we inserted the departments in that order, they would naturally
tend to be put together. If we inserted the departments in the order 10, 80, 20, 30, 40, 50,
60, and then 70, the final department, 70, would tend to be on the newly added block. As we’ll
see shortly, both the size of the data and the order in which the data is inserted will affect the
number of keys we can store per block.
The SIZE parameter therefore controls the maximum number of cluster keys per block. It
is the single largest influence on the space utilization of our cluster. Set the size too high, and
we’ll get very few keys per block and we’ll use more space than we need. Set the size too low,
and we’ll get excessive chaining of data, which offsets the purpose of the cluster to store all of
the data together on a single block. It is the most important parameter for a cluster.
Now for the cluster index on our cluster. We need to index the cluster before we can put
data in it. We could create tables in the cluster right now, but we’re going to create and populate
the tables simultaneously, and we need a cluster index before we can have any data. The
cluster index’s job is to take a cluster key value and return the block address of the block that
contains that key. It is a primary key in effect, where each cluster key value points to a single
block in the cluster itself. So, when we ask for the data in department 10, Oracle will read the
cluster key, determine the block address for that, and then read the data. The cluster key index
is created as follows:
ops$tkyte@ORA10GR1> create index emp_dept_cluster_idx
2 on cluster emp_dept_cluster
3 /
Index created.
It can have all of the normal storage parameters of an index and can be stored in another
tablespace. It is just a regular index, so it can be on multiple columns; it just happens to index
into a cluster and can also include an entry for a completely null value (see Chapter 11 for the
reason why this is interesting to note). Note that we do not specify a list of columns in this
CREATE INDEX statement—that is derived from the CLUSTER definition itself. Now we are ready
to create our tables in the cluster: