The amount of disk space required depends on the sizes of segments and pages that constitute RDAREAs. You should take this point into account when designing RDAREAs. Table 15-1 lists the items to be examined during RDAREA design, and Table 15-2 lists the maximum and minimum values for RDAREAs.
Table 15-1 Items to be examined during RDAREA design
Design task and items to be examined | Advantages | Disadvantages | Section | |
---|---|---|---|---|
Segment size | Size increased | If a row length changes as a result of update processing or if a row is added to a table for which a cluster key is specified, unused pages can be allocated that are adjacent to the page containing the specified row, thereby reducing the data input/output time. | Because the number of segments is reduced, the number of tables and indexes that can be stored per user RDAREA is also reduced. | 15.2.1 |
Size reduced | If many tables, each of which contains a small amount of data, are stored in one user RDAREA, wasted space caused by unused pages can be minimized. |
| ||
Per-cent-age of free space in segment | Specified | When data is added to a table for which a cluster key is specified, data can be stored in the page close to the cluster key value, thereby reducing the number of data input/output operations. | As the value becomes larger, more disk space is required. | 15.2.2 |
Set to 0 | The disk space required can be reduced. | When data is added to a table for which a cluster key is specified, data cannot be stored in the page close to the cluster key value, resulting in poor storage status; therefore, reduction in the number of data input/output operations is no longer beneficial. | ||
Page length | Percent-age of unused space in page specified |
| For a table with the FIX attribute, storage efficiency is poor. | 15.3.2 |
Percent-age of unused space in page set to 0 | For a table with the FIX attribute, storage efficiency is improved if the data is placed in ascending order. | If a row becomes longer than before as a result of update processing, the row spans multiple pages, resulting in overhead in row accesses. | ||
Free space reusage | Used |
| If there is insufficient free space for reuse, the overhead for free space search increases. | 15.5 |
Not used | If there is adequate free space, rapid insertion processing is possible. | RDAREA storage efficiency is reduced. Performance of free space search after the RDAREA is full is degraded. | ||
Shared RDAREA | Used | If a heavily accessed table that is difficult to partition is stored in a shared RDAREA, the efficiency of parallel processing improves because the table can be referenced by all back-end servers. | When a shared table is updated, the shared RDAREA containing the table is locked, and deadlock may occur if an application accesses another table in the shared RDAREA. | 15.6 |
Not used | Deadlock and server-to-server global deadlock, which sometimes result from use of a shared RDAREA, are avoided. | For complex search processing, such as join processing, overhead associated with connection establishment between multiple back-end servers and with data transfer increases. |
Table 15-2 Maximum and minimum values for RDAREAs
Item | Maximum and minimum values |
---|---|
Total number of RDAREAs | 3 to 8,388,592 |
Number of master directory RDAREAs | 1 |
Number of data directory RDAREAs | 1 |
Number of data dictionary RDAREAs | 1 to 41 |
Number of user RDAREAs | 1 to 8,388,589 |
Number of data dictionary LOB RDAREAs | 1 to 2 |
Number of user LOB RDAREAs | 0 to 8,388,325 |
Number of registry RDAREAs | 0 to 1 |
Number of registry LOB RDAREAs | 0 to 1 |
Number of list RDAREAs | 0 to 8,388,588 |
Number of HiRDB files per RDAREA | 1 to 16 |
Number of base tables per RDAREA | 0 to 500 |
Number of indexes per RDAREA | 0 to 500 |
Number of lists per RDAREA | 0 to 50,000 |
Total number of HiRDB files | 1 to 134,217,728 |