Nonstop Database, HiRDB Version 9 System Operation Guide

[Contents][Index][Back][Next]

13.11.1 Overview of the hash facility for hash row partitioning

When the data volume in a table with hash partitioning has increased and an RDAREA is added (that is, when the number of table row partitions is increased), an imbalance will occur between the amount of data in the existing RDAREAs and the amount of data in the newly added RDAREA. When the hash facility (rebalancing facility) for hash row partitioning is used, such an imbalance in the amount of data in the RDAREAs can be corrected. The following figure shows the hash facility for hash row partitioning.

Note that the hash facility for hash row partitioning can be applied to both FIX hashing and flexible hashing.

Figure 13-11 Hash facility for hash row partitioning

[Figure]

Explanation
  1. Because data has filled the hash partitioned table, an RDAREA for storing the hash partitioned table is added (the number of table row partitions is increased). No data is placed in the added RDAREA, resulting in a data volume imbalance.
  2. The rebalancing utility (pdrbal command) is executed to correct the data volume imbalance. Executing this utility relocates data by moving it by hash group. This is called table rebalancing.
    When the hash facility for hash row partitioning is used, HiRDB divides the data into 1,024 groups (called a hash group) based on the hashing result of the partitioning key. RDAREA segments are allocated to these groups to store the data. Data relocating is also carried out using the hash group as the unit.
Organization of this subsection
(1) Application criteria
(2) Note
(3) Procedure

(1) Application criteria

#: An RDAREA cannot be added to a table with FIX hash partitioning if data is stored in it (this applies to a table with FIX hash partitioning that uses one of the hash functions HASH1 to HASH6). However, with the rebalancing facility, an RDAREA can be added to a table with FIX hash partitioning that uses one of the hash functions HASHA to HASHF.

(2) Note

The amount of data in each hash group depends on the hashing result of the hash function. Therefore, if the partitioning key values are not distributed evenly, the data volume will also be uneven among the hash groups, and it might not be possible to divide the data evenly among the RDAREAs.

(3) Procedure

The following is an overview of the procedure for applying the hash facility for hash row partitioning.

Procedure
To apply the has facility:
  1. When a hash partitioned table is defined, define it as a rebalancing table.
  2. To increase the number of table row partitions, add an RDAREA to be used to store the table's data.
  3. Rebalance the table by executing the rebalancing utility.#
#: The execution modes shown in the following table are available for the rebalancing utility.

Table 13-2 Rebalancing utility execution modes

Execution mode Explanation
Shared mode Table can be accessed while it is being rebalanced.
In a very large database, table rebalancing might take as long as several days. Access to the table can be permitted while rebalancing is underway. However, because table access and table rebalancing are being executed simultaneously, the efficiency of both processes is degraded. To minimize such degradation, it is possible to divide the rebalancing process into multiple segments to be executed at times when the operational workload is low.
Exclusive mode Table cannot be accessed while it is being rebalanced.
Because only rebalancing is executed, processing efficiency is higher than in the shared mode. If it is possible to suspend accesses to the table, we recommend that you execute the rebalancing utility in the exclusive mode.
The rebalancing process can be divided into multiple segments in the exclusive mode as well.