Nonstop Database, HiRDB Version 9 System Operation Guide

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

13.12.12 Combining RDAREAs (matrix partitioning)

Organization of this subsection
(1) Maximum and minimum values
(2) Determining the RDAREAs for combining
(3) Determining the RDAREA to be used after combining
(4) RDAREA specification method
(5) Correspondence between a table and RDAREAs other than for the table
(6) Handling the data in RDAREAs to be combined

(1) Maximum and minimum values

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

Table 13-38 Maximum and minimum values for the combine facility (matrix partitioning)

Item Maximum value Minimum value What happens when the maximum or minimum value is exceeded?
Number of RDAREA groups storing specific boundary values that can be combined 16 2 An error occurs in ALTER TABLE.
Number of RDAREA groups storing specific boundary values following a single combining operation 1 (fixed)
Total number of split RDAREAs (excluding duplications) resulting from the combining process 1024 1

(2) Determining the RDAREAs for combining

All RDAREAs that satisfy specified storage conditions are selected for combining, based on multiple column names and boundary values to be changed, specified in CHANGE RDAREA of ALTER TABLE. Because specification of column names and boundary values to be changed identifies the target RDAREAs, there is no need to specify the RDAREAs themselves. The multiple boundary values must be specified in ascending order; they must also be specified to account for all the contiguous storage conditions defined for the table. For example, if boundary values 10, 20, 30, and 40 are defined in a table definition, specifying 10, 30, and 40 (and skipping specification of 20) will cause an error in ALTER TABLE.

The following table shows the specification of ALTER TABLE and how the RDAREAs to be combined are determined.

Table 13-39 ALTER TABLE specification and determination of RDAREAs to be combined (matrix partitioning)

Specification Condition 1 Condition 2 Action
Boundary value Boundary values are specified in the table definition. Boundary values are specified in the order in which they are defined. All RDAREAs that satisfy the specified storage conditions become the RDAREAs that will be combined.
Boundary values are not specified in their definition order. An error occurs in ALTER TABLE.
No boundary values are specified in the table definition. None
'MAX' None None RDAREAs in the RDAREA groups storing specific boundary values that store data with partitioning key values greater than the maximum boundary value will be combined.

(3) Determining the RDAREA to be used after combining

The RDAREA for storing all storage conditions after combining is determined by comparing RDAREAs with the post-change boundary value list (a combination of boundary values specified for a certain dimension) for the dimension specified in CHANGE RDAREA of ALTER TABLE. The combined boundary value must equal the maximum value of the pre-combination boundary values.

The post-combination RDAREA might be one of the pre-combination RDAREAs, or it might be a newly created RDAREA. The following table shows the RDAREAs that can be specified as the post-combination RDAREA.

Table 13-40 RDAREAs that can be specified as the post-combination RDAREA (matrix partitioning)

RDAREA Can it be used as the post-combination RDAREA?
Same as the pre-combination RDAREAs Yes
None of the pre-combination RDAREAs RDAREA that is already being used for a boundary value of the same table (but not a boundary value that is being combined) Yes
RDAREA that is not being used for this table (a newly created RDAREA) Yes

You can combine RDAREAs so that multiple storage conditions are stored in one RDAREA after combining.

(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 RDAREAs or the second-dimension RDAREAs are combined. The number of RDAREA groups storing specific boundary values that are combined, and the number of RDAREAs in an RDAREA group storing specific boundary values that are combined, depend on the number of splits in the dimension that is not combined. The following table shows the relationship between the dimension to be combined and the number of specified RDAREAs. The figure below displays the examples used in the table.

Table 13-41 Relationship between the dimension to be combined and the number of specified RDAREAs

Dimension to be combined Number of RDAREA groups storing specific boundary values that are to be combined Number of RDAREAs in an RDAREA group storing specific boundary values that are to be combined
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 changed boundary value list
(2 in Example 2 in the figure)

Figure 13-81 RDAREA specification following RDAREA combination (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 whose partitioning storage conditions are to be changed, the index data must be stored in RDAREAs that form pairs with table RDAREAs. The following table 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-42 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 one-to-one to the table RDAREAs.
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 index (including primary cluster index)
B-tree index

(6) Handling the data in RDAREAs to be combined

The general rule is that when storage ranges are combined based on a boundary value, the system automatically deletes the data from the RDAREAs. However, under some conditions, you can specify that the data be retained.

  1. Deleting data
    When storage ranges are combined based on a boundary value, the RDAREA group storing pre-combination specific boundary values will likely become RDAREAs that are not used by the table after combining. Therefore, the system automatically deletes the data from the RDAREAs. Note that only the data in the table whose partitioning storage conditions are to be changed is deleted; data in 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-combination RDAREA is not used for the table after combining has taken place, all information about the pre-combination 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 combination-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-combination RDAREA will still be used for the table after combining, the dictionary information and information managed within the RDAREA is not deleted, and only the data of the combination-target table in the RDAREA is deleted. If an RDAREA that is to be used after combining 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 these 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 storage ranges are combined based on a boundary value, the general rule is that the table data in the pre-combination 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-combination RDAREA group storing specific boundary values is used without modification as a part of a post-combination RDAREA group storing specific boundary values.
    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, however, that the system does not check whether all data in the RDAREA matches the pre-combination storage range as a result of combining.

    Table 13-43 WITHOUT PURGE clause specification and data handling (in the case of matrix partitioning)

    Use of the RDAREA after change Can the WITHOUT PURGE clause be specified? Action when the WITHOUT PURGE clause is specified Action when the WITHOUT PURGE clause is not specified
    Pre-combination RDAREA group storing specific boundary values will be included in the post-combination RDAREA group storing specific boundary values. Yes Does not delete the data from the post-combination RDAREA group storing specific boundary values. Deletes all data from the pre-combination RDAREA group storing specific boundary values.
    Pre-combination RDAREA group storing specific boundary values will not be included in the post-combination RDAREA group storing specific boundary values. No Deletes all data from the pre-combination RDAREA group storing specific boundary values.
  3. Notes on cases in which data is not deleted
    When you save data by specifying the WITHOUT PURGE clause, if all pre-combination data is unloaded and loaded into a post-combination RDAREA, the saved data ends up being registered in duplicate. Therefore, when you save RDAREA data by specifying the WITHOUT PURGE clause, do not unload the data or load it after combining.
    Even when the WITHOUT PURGE clause is specified, all data is deleted from any RDAREA that is part of the pre-combination RDAREA group storing specific boundary values, but is not part of the post-combination RDAREA group storing specific boundary values. Furthermore, if an RDAREA is being used for a storage condition other than those that are combined and if that RDAREA is not used after combination, data is also deleted from the other storage condition value. Therefore, when you combine specific storage ranges within RDAREAs that are used in multiple storage ranges, you must change the partitioning storage conditions without specifying the WITHOUT PURGE clause, and then load the unloaded data into the combined RDAREA.
    The following figure shows how to handle RDAREAs that undergo changes (when the WITHOUT PURGE clause is specified).

    Figure 13-82 Handling RDAREAs that undergo changes (when the WITHOUT PURGE clause is specified)

    [Figure]

  4. Notes on deleting data
    As explained above under Notes on cases in which data is not deleted, if an RDAREA is being used by a storage condition other than those that are combined, and if that RDAREA is not used after combination, data is also deleted from the other storage range. Therefore, when combination-target RDAREAs are also being used for storage conditions other than those in the combination range, we recommend that you unload all data from the combination-target RDAREAs, change the partitioning storage conditions without specifying the WITHOUT PURGE clause, and then load the unloaded data into the combined RDAREA.