The tables are primarily queried--that is, tables that are not predominantly inserted into or updated.
Records from the tables are frequently queried together or joined.
Choose cluster key columns carefully. If multiple columns are used in queries that join the tables, make the cluster key a composite key. In general, the characteristics that indicate a good cluster index are the same as those for any index. For information about characteristics of a good index, see "Guidelines for Managing Indexes".
A good cluster key has enough unique values so that the group of rows corresponding to each key value fills approximately one data block. Having too few rows for each cluster key value can waste space and result in negligible performance gains. Cluster keys that are so specific that only a few rows share a common value can cause wasted space in blocks, unless a small
SIZE was specified at cluster creation time (see "Specify the Space Required by an Average Cluster Key and Its Associated Rows").
Too many rows for each cluster key value can cause extra searching to find rows for that key. Cluster keys on values that are too general (for example,
female) result in excessive searching and can result in worse performance than with no clustering.
A cluster index cannot be unique or include a column defined as
CREATE CLUSTER statement has an optional clause,
SIZE, which is the estimated number of bytes required by an average cluster key and its associated rows. The database uses the
SIZE parameter when performing the following tasks:
Estimating the number of cluster keys (and associated rows) that can fit in a clustered data block
Limiting the number of cluster keys placed in a clustered data block. This maximizes the storage efficiency of keys within a cluster.
SIZE does not limit the space that can be used by a given cluster key. For example, if
SIZE is set such that two cluster keys can fit in one data block, any amount of the available data block space can still be used by either of the cluster keys.
By default, the database stores only one cluster key and its associated rows in each data block of the cluster data segment. Although block size can vary from one operating system to the next, the rule of one key for each block is maintained as clustered tables are imported to other databases on other machines.
If all the rows for a given cluster key value cannot fit in one block, the blocks are chained together to speed access to all the values with the given key. The cluster index points to the beginning of the chain of blocks, each of which contains the cluster key value and associated rows. If the cluster
SIZE is such that more than one key fits in a block, blocks can belong to more than one chain.
If you have the proper privileges and tablespace quota, you can create a new cluster and the associated cluster index in any tablespace that is currently online. Always specify the
TABLESPACE clause in a
INDEX statement to identify the tablespace to store the new cluster or index.
The cluster and its cluster index can be created in different tablespaces. In fact, creating a cluster and its index in different tablespaces that are stored on different storage devices allows table data and index data to be retrieved simultaneously with minimal disk contention.
You can use the combined estimated size of clusters, along with estimates for indexes and redo log files, to determine the amount of disk space that is required to hold an intended database. From these estimates, you can make correct hardware purchases and other decisions.
You can use the estimated size of an individual cluster to better manage the disk space that the cluster will use. When a cluster is created, you can set appropriate storage parameters and improve I/O performance of applications that use the cluster.
Set the storage parameters for the data segments of a cluster using the
STORAGE clause of the
CLUSTER statement, rather than the individual
ALTER statements that put tables into the cluster. Storage parameters specified when creating or altering a clustered table are ignored. The storage parameters set for the cluster override the table storage parameters.