Key range partitioning is the prerequisite for this method. The following table shows whether partitioning storage conditions can be changed for each table partitioning method.

Table 13-3 Table partitioning methods for which partitioning storage conditions can be changed

Table partitioning method			Applicability
Key range partitioning	Storage condition specification	Only = is used as the comparison operator for storage conditions	Y
		A condition other than = is used as the comparison operator for storage conditions	N
	Boundary values specification		Y
Hash partitioning (including rebalancing)	FIX hash not specified		N#1
	FIX hash specified
Matrix partitioning	Combination of key range partitioning with boundary value specification		Y#2
	Combination of key range partitioning with boundary value specification and hash partitioning		Y#3

Legend:

Y: Can be changed.

N: Cannot be changed.

#1

Only RDAREA addition is supported by the ALTER TABLE definition SQL statement with ADD RDAREA specified.

#2

Can be changed by only one dimension at each execution.

#3

Only key range partitioning dimensions that use boundary value specification can be changed.

Partitioning storage conditions cannot be changed for the following types of tables:

• Non-partitioned table: Because there are no partitioning storage conditions for a non-partitioned table, change is not possible.
• Falsification-prevented table: Depending on the specified change in the partitioning storage conditions, data in the target table in the RDAREA might be deleted. Because data deletion is the same as data falsification, the partitioning storage conditions for a falsification prevented table cannot be changed.
• Table containing an abstract data type: The partitioning storage conditions of a table containing an abstract data type cannot be changed.

To change partitioning storage conditions, you need HiRDB Advanced High Availability. If you attempt to change the partitioning storage conditions (CHANGE RDAREA of ALTER TABLE) and this product has not been set up, the KFPA11948-E message will be displayed and ALTER TABLE will terminate with an error.

(a) Indexes

If an index has been defined for a table whose partitioning storage conditions are to be changed, it might not be possible to change the partitioning storage conditions depending on the index definition conditions. The following table shows whether the partitioning storage conditions can be changed for each type of index.

Table 13-4 Index types for which partitioning storage conditions can be changed

Index type	Partitioned/Non-partitioned index	Applicability
Cluster key index	Partitioned key index	Y#1
Primary key index (including an index for which a primary key and cluster key are defined)
B-tree index	Partitioned key index	Y#1
	Non-partitioned key index	Y#1, #2
Plug-in index	Not applicable	N

Legend:

Y: Can be changed.

N: Cannot be changed.

#1

Depending on the partitioning conditions for the index storage RDAREAs, it might not be possible to change the partitioning storage conditions. Table 13-5 Whether the partitioning storage conditions can be changed depending on the partitioning conditions for the index storage RDAREAs shows whether the partitioning storage conditions can be changed, depending on the partitioning conditions that are applicable to the index storage RDAREAs.

#2

If the index storage RDAREAs have a 1-to-1 partition correspondence with the table storage RDAREAs, the partitioning storage conditions can be changed. Table 13-6 Applicability of changing partitioning storage conditions for a non-partitioning key index shows whether changing the partitioning storage conditions applies to a non-partitioning key index.

Table 13-5 Whether the partitioning storage conditions can be changed depending on the partitioning conditions for the index storage RDAREAs

Partitioning conditions for the index storage RDAREAs			Whether the partitioning storage conditions can be changed
			Split	Combine
Partitioning key index	Index storage RDAREAs are partitioned.		Y	Y#1
	Index storage RDAREAs are not partitioned.		N#2	N#3
Non-partitioning key index	Partitioning is performed in such a manner that the table storage RDAREAs and index storage RDAREAs have a 1-to-1 correspondence.	Index storage RDAREAs are partitioned.	Y	Y#1
		Index storage RDAREAs are not partitioned.	N#2	N#3
	Other		N	N

Legend:

Y: Partitioning storage conditions can be changed.

N: Partitioning storage conditions cannot be changed.

#1

If the total number of index storage RDAREAs is reduced after combining to a single index storage RDAREA, the partitioning storage conditions can no longer be changed because the row-partitioned index has been converted to a non-row-partitioned index.

#2

The partitioning storage conditions cannot be changed because the non-row-partitioned index is converted to a row-partitioned index.

#3

A row-partitioned index can be changed to a non-row-partitioned index only when the target table is stored in a single RDAREA. Therefore, the partitioning storage conditions cannot be changed.

If the partitioning storage conditions cannot be changed due to the relationship between index storage RDAREAs and table storage RDAREAs, delete the applicable index first, execute ALTER TABLE, and then re-define the index.

Figure 13-19 Case in which a table storage RDAREA cannot be split (part 1) and Figure 13-20 Case in which a table storage RDAREA cannot be split (part 2) show cases in which a table storage RDAREA cannot be split.

Figure 13-19 Case in which a table storage RDAREA cannot be split (part 1)

Figure 13-20 Case in which a table storage RDAREA cannot be split (part 2)

Table 13-6 Applicability of changing partitioning storage conditions for a non-partitioning key index

Table RDAREAs		Index RDAREAs
Row partitioning between servers	Row partitioning within servers	Row partitioning between servers	No row partitioning between servers
Yes	Yes	Y	N
	No	--	Y#
No	Yes	Y	N
	No	--	--

Legend:

Y: Can be changed.

N: Cannot be changed.

--: Not applicable.

#: Cannot be changed if multiple partitioning storage conditions are stored in the same RDAREA.

(b) RDAREAs storing LOB and indexes

If RDAREAs storing LOB and indexes are defined for a table whose partitioning storage conditions are to be changed, these RDAREAs must also be partitioned or combined along with the table in the same manner.

(c) RDAREAs after change

RDAREAs after the change cannot be used for the following purposes:

• RDAREA that is not a user RDAREA cannot be used as a table or index RDAREA
• RDAREA that is not a user LOB RDAREA cannot be used as a BLOB column RDAREA
• Shared RDAREA
• RDAREA for storing a rebalancing table or resources related to a rebalancing table
• RDAREA of a replica generation when the inner replica facility is used (must be an RDAREA of the original generation)