Partitioning databases with secondary indexes
The following topics discuss considerations for partitioning HDAM and HIDAM databases with secondary indexes.
Changing Secondary Index DBDs and IDCAMS Definitions
You do not change the DBD or IDCAMS definition for a secondary index of a partitioned database. You use the same DBD definition as you would use for a secondary index of a nonpartitioned database. The IDCAMS DEFINE CLUSTER, CI record size, and key are also the same, regardless of whether the source and target segment are in a partitioned or nonpartitioned database.
It is very important that you do not change the DBD or IDCAMS definition because there are often several secondary indexes for a large database. When converting a database to partitioned, if you do not change the secondary index definitions, it simplifies the conversion process.
The key order of a secondary index is not the same as the root key order of the partitioned target database. The secondary index records, therefore, will not be in partition order like a primary index.
Using Direct and Symbolic Pointers
Partitioned databases support both direct and symbolic pointers.
- For symbolic pointers, you use the root key in the symbolic pointer to determine the partition of the target segment.
- For direct pointers, the partition number of the target (and source) segment is stored in the secondary index record. For consistency, the partition number is stored in the secondary index record for both direct and symbolic pointers.
Symbolic pointers have an advantage during database reorganization because you do not have to update the secondary index unless you are using /SX fields.
Using Unique Secondary Indexes
Secondary indexes for partitioned databases must be unique. This restriction is imposed because non-unique secondary indexes using the KSDS/ESDS pair are not needed any longer. The /SX system related field can be used to make any non-unique secondary index unique.
Using Shared Secondary Indexes
A secondary index for partitioned databases cannot be a shared secondary index. A shared secondary index is not the same as a secondary index using data sharing. The shared secondary index that is not supported is where multiple secondary indexes are in the same DBD, and CONSTANT in the indexed DBD is used to allow the index records to be in the same KSDS.
Shared secondary indexes do not make sense with large databases, and they are rarely used. For these reasons, shared secondary indexes are not supported with partitioned databases.
Using /SX System Related Fields
You define the /SX system related field in the source segment of the indexed DBD to make a secondary index unique.
The /SX is the four-byte RBA of the source segment. With nonpartitioned databases, where all segments of the same type are in the same data set, the source segment RBA is always unique. Source segments in partitioned databases are in multiple data sets; consequently, the RBA is not unique across all partitions.
The partition number is added to the /SX field to make the RBA unique. The partition number is relative to zero, and only the bits necessary to hold the partition number are used. RBAs must always be even numbers, so the low bit of the RBA can also be used.
The /SX field is still only four-bytes. With the low-bit being used, the four-bytes allow up to eight GB of unique RBAs. It is possible, although not very likely, for very large databases to have duplicate keys. The /SX field is incremented by 1 and reinserted if there is a duplicate key to ensure the index is unique.
By incrementing the /SX field by one when duplicates occur, the index is unique and the index can be retrieved efficiently. Duplicates are very rare because the search key, any other subsequence fields, partition number and /SX RBA must all be the same.
When duplicates do occur, the target RBA (direct pointers) or symbolic key in the index record is used to ensure the correct index record is retrieved by DL/1 index maintenance.