Nonstop Database, HiRDB Version 9 System Operation Guide

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

13.12.6 Combining RDAREAs (in the case of boundary value specification)

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) Correspondence between a table and RDAREAs other than for the table
(5) Handling the data in the RDAREAs to be combined

(1) Maximum and minimum values

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

Table 13-13 Maximum and minimum values for the combine facility (in the case of boundary value specification)

Item Maximum and minimum values What happens when the maximum or minimum value is exceeded?
Number of RDAREAs that can be combined 2-16 (minimum is 2, maximum is 16) Causes an error in ALTER TABLE.
Number of RDAREAs following a single combining operation 1 (fixed)
Total number of RDAREAs in the combined table 2 (minimum)

(2) Determining the RDAREAs for combining

All RDAREAs that satisfy specified storage conditions are selected for combining, based on multiple boundary values for the combination-target RDAREAs specified in CHANGE RDAREA of ALTER TABLE. Because specification of boundary values 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 ALTER TABLE specification and how to determine which RDAREAs are to be combined.

Table 13-14 ALTER TABLE specification and determination of which RDAREAs to combine (in the case of boundary value specification)

Specification Condition 1 Condition 2 Action
Boundary values Boundary values are specified in the table definition. Boundary values are specified in the order in which they are defined. RDAREAs that satisfy the specified storage conditions are combined.
Boundary values are not specified in their definition order. Causes an error in ALTER TABLE.
No boundary values are specified in the table definition. None
'MAX' Boundary value specified immediately before is the maximum boundary value in the table definition. None RDAREAs storing data with partitioning key values greater than the maximum boundary value are combined.
Boundary value specified immediately before is not the maximum boundary value in the table definition. None Causes an error in ALTER TABLE.

(3) Determining the RDAREA to be used after combining

The post-combination RDAREA specified in CHANGE RDAREA of ALTER TABLE becomes the RDAREA that stores all the specified pre-combination storage conditions. Because the boundary value after the combining operation is a merger of the boundary values that were combined, there is no need to specify it. For example, if the boundary values are 10, 20, 30, and 40, and a combining operation combines 20 and 30, the new boundary values become 10, 30, and 40. In this case, all data that is greater than 10 but equal to or smaller than 30 satisfies the storage condition for the combined RDAREA.

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

Table 13-15 RDAREAs that can be specified as the post-combination RDAREA (in the case of boundary value specification)

RDAREA Can be used as the post-combination RDAREA?
Any one of 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

Legend:
--: Not applicable

You can combine RDAREAs so that multiple storage conditions are stored in one RDAREA after combining. However, you cannot combine RDAREAs such that all data is stored in a single RDAREA after combining. The following figure shows an example of a combining operation that is not allowed (one that combines all data into a single RDAREA).

Figure 13-30 Example of a combining operation that is not allowed (which combines all data into a single RDAREA)

[Figure]

You cannot combine RDAREAs such that the post-combination RDAREA also stores the preceding or succeeding storage range. In this case, you must combine the RDAREAs by also including the preceding or succeeding RDAREA. The following figure shows an example of a combining operation that is not allowed (where the post-combination RDAREA is the same RDAREA that stores the preceding storage range).

Figure 13-31 Example of a combining operation that is not allowed (the post-combination RDAREA also stores the preceding storage range)

[Figure]

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

When an item such as a partitioning key index is defined for a table whose partitioning storage conditions need to be changed, the index data must be stored in the RDAREA that forms a pair with the table storage RDAREA. The table below shows how to specify a table and RDAREAs other than for the table (combining storage conditions when boundary values are partitioned). If more than one unit of a resource such as those shown in the table 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. The figure below shows the correspondence between a table and RDAREAs other than for the table.

Table 13-16 Specifying a table and RDAREAs other than for the table (combining storage conditions when partitioning boundary values)

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 duplicate table RDAREAs are specified, specify duplicate resources so that they correspond to the table. If an existing table RDAREA is to be used after the change, you must specify 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

Figure 13-32 Example of the correspondence between a table and RDAREAs other than for the table

[Figure]

(5) Handling the data in the RDAREAs to be combined

The general rule is that when storage ranges are combined based on boundary values, the system automatically deletes the applicable table's existing table data from the RDAREAs. However, under some conditions, you can specify that data is to be retained.

  1. Deleting data
    When storage ranges are combined based on boundary values, pre-combination RDAREAs might no longer be used by the table after combining. Therefore, the system automatically deletes the data in those RDAREAs. Note that only the data in the table whose partitioning storage conditions are to be changed is deleted; data of other tables contained in the RDAREA is not deleted. One of the following methods is used to delete the data from the RDAREA:
    • Deleting all definition information
      If a 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 RDAREA information in the dictionary table (SQL_DIV_TABLE table) 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 a pre-combination RDAREA is to be used as the RDAREA for the combined storage ranges, the dictionary information and information managed within the RDAREA is not deleted, and only the table's data in the RDAREA is deleted. If the RDAREA to be used for the combined storage ranges 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 storage ranges are combined based on boundary values, the general rule is that the table's data in the pre-combination RDAREAs is deleted. However, the data in an RDAREA can be used as is if the condition listed below is satisfied, and therefore it is possible to avoid deletion of such data:
    • The pre-combination RDAREA is to be used without modification as the post-combination RDAREA.
    To instruct that the data in the RDAREA is not to be deleted, you must specify the WITHOUT PURGE clause in ALTER TABLE. The following table shows whether the data is deleted depending on the specification of the WITHOUT PURGE clause.

    Table 13-17 WITHOUT PURGE clause specification and data handling (in the case of boundary value specification)

    Use of the RDAREA after combining Can the WITHOUT PURGE clause be specified? Action when the WITHOUT PURGE clause is specified. Action when the WITHOUT PURGE clause is not specified.
    One of the pre-combination RDAREAs will be used as the post-combination RDAREA Yes Does not delete the data from the RDAREA to be re-used after combining; deletes data from the other pre-combination RDAREAs. Deletes the data from all pre-combination RDAREAs.
    No pre-combination RDAREA will be used as the post-combination RDAREA (a different RDAREA from any of the pre-combination RDAREAs is to be used as the post-combination RDAREA) No Causes an error in ALTER TABLE.
    The following figure shows the RDAREAs from which data is deleted during combining.

    Figure 13-33 RDAREAs from which data is deleted during combining

    [Figure]

    [Figure]

  3. Notes on cases in which data is not deleted
    If you specify WITHOUT PURGE to save the data, then you unload all the data before combining and reload it into the post-combination RDAREA, the data saved by the WITHOUT PURGE specification will have been registered twice. For this reason, you must not execute unloading and post-combination reloading of the data of an RDAREA if that RDAREA's data is being saved by specification of WITHOUT PURGE.
    Even if you specify WITHOUT PURGE, the data in any pre-combination RDAREA that is not used as the post-combination RDAREA is deleted. Also, if an RDAREA containing a storage range to be combined is not to be used as the post-combination RDAREA and that pre-combination RDAREA also contains a storage range that is not included in the combining operation, the data in this other storage range will also be deleted. Therefore, to combine one or more selected storage ranges in an RDAREA that stores multiple storage ranges, it is necessary to change the partitioning storage conditions without specifying WITHOUT PURGE, and then reload the combined RDAREA with the data that has been unloaded.
    The following figure shows examples of handling data in the RDAREAs to be combined when WITHOUT PURGE is specified.

    Figure 13-34 Examples of handling data in the RDAREAs to be combined (when WITHOUT PURGE is specified)

    [Figure]

  4. Notes on deleting data
    As explained in the notes on not deleting data, if there is an RDAREA that is being used for a storage range that is not to be included in the combining operation, as well as for a storage range that will be included in the combining operation, and this RDAREA will not become the post-combination RDAREA, the data in the other storage range is also deleted. For this reason, we recommend in this case that you unload all data from the RDAREAs to be combined, change the partitioning storage conditions without specifying WITHOUT PURGE, and then reload the combined RDAREA with the data that has been unloaded.