The following figure provides an overview of changing partitioning storage conditions (in the case of boundary value specification).

Figure 13-12 Overview of changing partitioning storage conditions (in the case of boundary value specification)

Explanation

1. The combine facility combines the 1999 and 2000 storage conditions (definition information), which are stored in RDAREAs R01 and R02, respectively, and stores them in RDAREA R02. At this time, the data from R01 can be deleted.
2. The split facility splits the storage condition (definition information) for 2002 into the data for 2002 and the data for 2003. As a result, the 2002 data is stored in R04 and the data for 2003 and beyond can be stored in R01, which previously stored the data for 1999, thereby reusing R01.

Therefore, in step 1, all that is needed is to unload the data from R01 and R02 and then, after the partitioning storage conditions have been changed, to reload the data from R02 only. In step 2, all that is needed is to unload the data from R04 and load data into R04 and R01 after the partitioning storage conditions have been changed. It was also possible to delete the contents of R01 in step 1. If R04 did not contain any data for 2003 and beyond, unloading and loading would be unnecessary, and thus the RDAREA configuration could be modified quite quickly. This makes it possible to recycle and reuse RDAREAs that store data that increases in volume as new ascending key values are added.

The following figure provides an overview of changing partitioning storage conditions (in the case of storage condition specification).

Figure 13-13 Overview of changing partitioning storage conditions (in the case of storage condition specification)

Explanation

The table is row-partitioned with a storage condition specification that uses the branch name as the key value. When branches need to be deleted or added due to restructuring, data for a single branch can be split into multiple branches or data for multiple branches can be combined into a single branch.

1. Because the Berkeley and Oakland branches are combined, the data from these branches is combined in RDAREA R02 and the data in RDAREA R01 is deleted.
2. Because the San Jose branch is split from the San Francisco branch, the data in RDAREA R04 is split. The data for the San Jose branch is stored in R04 and the data for the San Francisco branch is stored in RDAREA R05.
   

   Hint

   • In 1., data must be unloaded only from R01 and R02. There is no need to unload data from R03 or R04.
   • In 2., data must be unloaded only from R04. There is no need to unload data from R02 or R03.

The following figure provides an overview of changes in the partitioning storage conditions (in the case of matrix partitioning).

Figure 13-14 Overview of changes in partitioning storage conditions (in the case of matrix partitioning)

Explanation:

1. When the second-dimension partitioning storage conditions are combined, the storage conditions (definition information) for the years 2004 and earlier and the year 2005, which were stored in RDAREAs (RD11, RD12, RD21, RD22, RD31, and RD32), are combined into a single unit and stored in RDAREAs RD12, RD22, and RD32. At the same time, the data is deleted from RDAREAs RD11, RD21, and RD31.
2. When the partitioning storage conditions are conditioned, the storage conditions for the year 2007 are partitioned into storage conditions for the years 2007 and 2008. Data for the year 2007 is stored in RDAREAs RD14, RD24, and RD34; data for the year 2008 and beyond is stored in RDAREAs RD15, RD25, and RD35.