Nonstop Database, HiRDB Version 9 System Operation Guide

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

13.12.11 Partitioning an RDAREA (matrix partitioning)

Data that is partitioned using either dimension, which is used as a partitioning key for a matrix-partitioned table, is partitioned into multiple RDAREAs. The facility details are as follows.

Organization of this subsection
(1) Maximum and minimum values
(2) Determining the RDAREA to split
(3) Determining the post-splitting RDAREA
(4) RDAREA specification method
(5) Correspondence between a table and RDAREAs other than for the table
(6) Handling the data in an RDAREA to be split

(1) Maximum and minimum values

The following table shows the maximum and minimum values for the split facility.

Table 13-32 Upper and lower limits for the split facility (matrix partitioning)

Item Maximum value Minimum value What happens when the maximum or minimum value is exceeded?
Number of dimensions that can be changed 1 (fixed) Cannot be specified.
Number of RDAREA groups storing specific boundary values that can be partitioned# 1 (fixed)
Number of partitions that can be made in a single operation 16 2 Causes an error in ALTER TABLE.
Total number of post-split partitioned RDAREAs (excluding duplicate RDAREAs) 1024 1
Total number of post-split partitioned RDAREAs (including duplicate RDAREAs) 3000 4

#
The number of RDAREA groups storing specific boundary values is the number of RDAREA groups that store the data for specific storage conditions. For example, the RDAREA groups storing specific boundary values for the boundary value 2000 of the second-dimension partitioning column are RD12, RD22, RD32, and RD42.
[Figure]

(2) Determining the RDAREA to split

The RDAREA that satisfies a specified storage condition is selected for splitting, based on the column name and boundary value to be changed, specified in CHANGE RDAREA of the ALTER TABLE definition SQL. Because specifying a column name to be changed and a boundary value identifies the target RDAREA, there is no need to specify the RDAREA itself. The dimension of the partitioning target is determined based on the column name to be changed, specified in CHANGE RDAREA of the ALTER TABLE definition SQL. The following table shows the boundary value specification of ALTER TABLE and how to determine which RDAREA to split.

Table 13-33 ALTER TABLE specification and determination of which RDAREA to split (matrix partitioning)

Specified content Condition Can it be specified? Determination of RDAREA to split
Boundary value The table definition contains a boundary value that corresponds to the change-target column name. Y An RDAREA in the RDAREA group storing a specific boundary value that matches the storage condition becomes the partitioning target.
The table definition does not contain a boundary value that corresponds to the change-target column name. N --
'MAX' -- Y An RDAREA that stores data for the partitioning key value that is greater than the maximum boundary value becomes the partitioning target.

Legend:
Y: Can be specified.
N: Cannot be specified.
--: Not applicable

(3) Determining the post-splitting RDAREA

The RDAREA for storing data is determined by pairing RDAREAs with the changed boundary value list (a combination of boundary values specified for a certain dimension) for the dimension specified in CHANGE RDAREA of ALTER TABLE. The post-split boundary values must satisfy the following conditions:

The following table shows the ALTER TABLE specification values and how the post-splitting RDAREA is determined. The figure below shows the boundary value conditions before and after the split referenced in the table.

Table 13-34 ALTER TABLE specification and determination of post-splitting RDAREA (matrix partitioning)

Pre-splitting boundary value Post-splitting boundary value specification Condition Can it be specified? Determination of post-splitting RDAREA
Minimum boundary value
(1 in the figure)
Boundary value Post-splitting boundary value is equal to or less than the minimum boundary value (1 and 4 in the figure). Y Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.
Post-splitting boundary value is greater than the minimum boundary value (2, 3, and 5 in the figure). N Causes an error in ALTER TABLE.
'MAX' -- N
Intermediate boundary value or maximum boundary value (2 in the figure) Boundary value Post-splitting boundary value is less than the boundary value that precedes the pre-splitting boundary value (1. and 4. in the figure when the pre-splitting boundary value is 200). N Causes an error in ALTER TABLE.
Post-splitting boundary value is equal to or less than the pre-splitting boundary value, and is greater than the preceding boundary value (when the pre-splitting boundary value is 200, the range includes 200 and 5. in the figure). Y Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.
Post-splitting boundary value is greater than the pre-splitting boundary value (greater than 200 when the pre-splitting boundary value is 200). N Causes an error in ALTER TABLE.
'MAX' -- N
'MAX'
(3 in the figure)
Boundary value Post-splitting boundary value is equal to or less than the maximum boundary value (1, 2, 4, and 5. in the figure). N Causes an error in ALTER TABLE.
Post-splitting boundary value is greater than the maximum boundary value (3 in the figure) Y Specified storage conditions and RDAREAs are used to select the post-splitting RDAREAs.
'MAX' -- N RDAREA specified to store the data that is greater than the maximum boundary value.

Legend:
Y: Can be specified.
N: Cannot be specified.
--: Not applicable

Figure 13-78 Boundary value conditions before and after splitting (in the case of matrix partitioning)

[Figure]

The post-splitting RDAREAs might include (reuse) the pre-splitting RDAREA or might be all newly created. Furthermore, after splitting, multiple (non-contiguous) storage ranges can be stored in the same RDAREA.

(4) RDAREA specification method

In the case of a matrix-partitioned table, the method of specifying the RDAREA for CHANGE RDAREA of ALTER TABLE differs depending on whether the first-dimension RDAREA or the second-dimension RDAREA is split. The number of RDAREA groups storing specific boundary values that are to be split, as well as the number of RDAREAs in an RDAREA group storing specific boundary values that are to be split, depend on the number of splits in the dimension that is not to be split. The following table shows the relationship between the dimension to be split and the number of specified RDAREAs. The figure below shows the examples used in the table.

Table 13-35 Relationship between the dimension to be split and the number of specified RDAREAs

Dimension to be split Number of RDAREA groups storing specific boundary values that are to be split Number of RDAREAs in an RDAREA group storing specific boundary values that are to be split
First dimension Number of boundary values specified in the changed boundary value list
(2 in Example 1 in the figure)
Number of splits in the second dimension
(3 in Example 1 in the figure)
Second dimension Number of splits in the first dimension
(4 in Example 2 in the figure)
Number of boundary values specified in the post-change boundary value list
(2 in Example 2 in the figure)

Figure 13-79 RDAREA specification following RDAREA split (matrix partitioning)

[Figure]

(5) Correspondence between a table and RDAREAs other than for the table

When a partitioning key index or the like is defined for a table, the index data also must be stored in RDAREAs. If the partitioning storage conditions are changed for the table, the index must be split in the same way that the table RDAREAs are partitioned. The table below shows how to specify a table and RDAREAs other than for the table (matrix partitioning). If more than one unit of a resource such as is shown in the table below is defined, the specification method must be applied to each of them. If any specification is incorrect, the system causes an error in ALTER TABLE.

Table 13-36 Specifying a table and RDAREAs other than for the table (matrix partitioning)

Resource name Specification method
Column BLOB column Specify these resources so that they correspond to the table RDAREAs on a one-to-one basis.
If a table RDAREA is specified more than once, specify the resources more than once also so that they correspond to the specified tables. If the existing table RDAREA is to be used after the change, you must specify the RDAREAs for storing the existing indexes and LOB data so that they correspond to the same boundary values.
Index Cluster key index
Primary key index (including an index for which the primary key and a cluster key are defined)
B-tree index

(6) Handling the data in an RDAREA to be split

The general rule is that when a storage range is split based on a boundary value, the system automatically deletes the applicable table's existing table data from the RDAREA. However, under some conditions, you can specify that the data be retained.

  1. Deleting data
    When a storage range is split based on a boundary value, some of the data in the RDAREA group storing specific boundary conditions to be split will likely become data that will not be stored in that RDAREA after splitting. Therefore, all the data in the RDAREA group storing specific boundary conditions to be split must be deleted. Note that only the data in the table whose partitioning storage conditions are to be changed is deleted; data of other tables contained in that RDAREA is not deleted. One of the following methods is used to delete the data from the RDAREA:
    • Deleting all definition information
      If the pre-splitting RDAREA is not used for the table after splitting has taken place, all information about the pre-splitting RDAREA is deleted from the dictionary (SQL_DIV_TABLE table) containing the RDAREA information used by the table for each of the storage conditions. Table information that is managed within the RDAREA is also deleted. As a result, all data from the splitting-target table that existed in the RDAREA is deleted. In concept, this is equivalent to executing DROP TABLE for the RDAREA.
    • Deleting data only
      If the pre-splitting RDAREA will still be used for the table after splitting, the dictionary information and information managed within the RDAREA is not deleted, and only the data of the splitting-target table in the RDAREA is deleted. If an RDAREA that is to be used after splitting is already being used for another storage range, the data in this other storage range is also deleted. In concept, this is equivalent to executing PURGE TABLE for that RDAREA.
    Note that when data in an RDAREA is deleted, all data in the following corresponding RDAREAs is also deleted:
    • Index keys in an index RDAREA
    • Data in a BLOB column RDAREA
    Additionally, if the inner replica facility is being used, all generation data is deleted.
  2. Saving data
    As explained in 1. Deleting Data, when a storage range is split based on a boundary value, the general rule is that the table data in the pre-splitting RDAREA is deleted. However, the data in the RDAREA can be used as is if all the conditions listed below are satisfied. In this case you can avoid deletion of such data:
    • The pre-splitting RDAREA group storing specific boundary values is to be used without modification as part of a post-splitting RDAREA group storing specific boundary values.
    • All the existing data is at or below the boundary value for the pre-splitting RDAREA.
    • All data in the pre-splitting RDAREA group storing specific boundary values will be within the storage range for the same RDAREA group after splitting.
    To specify that the data in the RDAREA not be deleted, you must specify the WITHOUT PURGE clause in ALTER TABLE. The table below shows whether the data is deleted depending on the specification of the WITHOUT PURGE clause. Note that the system does not check whether all the data in the RDAREA matches the storage ranges after splitting.

    Table 13-37 WITHOUT PURGE clause specification and data handling (matrix partitioning)

    Use of the RDAREA after splitting Can the WITHOUT PURGE clause be specified? Action when the WITHOUT PURGE clause is specified Action when the WITHOUT PURGE clause is not specified
    The pre-splitting RDAREA group storing specific boundary values will be used as a post-splitting RDAREA group storing specific boundary values. Yes Does not delete the data from the pre-splitting RDAREA group storing specific boundary values. Deletes the data from the pre-splitting RDAREA group storing specific boundary values.
    Pre-splitting RDAREA group storing specific boundary values will not be used as a post-splitting RDAREA group storing specific boundary values. No Causes an error in ALTER TABLE.

The following figure shows examples in which specification of the WITHOUT PURGE clause is valid and invalid.

Figure 13-80 Examples in which specification of the WITHOUT PURGE clause is valid and invalid

[Figure]

Notes on cases in which data is not deleted
There might be data in the pre-splitting RDAREA that will not be within the applicable storage range after splitting (this type of data validity is not checked during execution of ALTER TABLE). Consequently, as a result of a change in partitioning storage conditions, there might be data outside the new storage range in the post-splitting RDAREA. If this happens, HiRDB might not function correctly during SQL execution.

Notes on deleting data
If the pre-splitting RDAREA contains data that will be stored in another storage range, data in this other storage range will also be deleted. This holds true regardless of whether the pre-splitting RDAREA will be used as a post-splitting RDAREA.