14.1 Items to be examined during RDAREA design

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 14-1 lists the items to be examined during RDAREA design, and Table 14-2 lists the maximum and minimum values for RDAREAs.

Table 14-1 Items to be examined during RDAREA design

Design task and items to be examinedAdvantagesDisadvantagesSection
Segment sizeSize increasedIf 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.14.2.1
Size reducedIf 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.
  • If a large amount of data is added to a user RDAREA, the number of segment allocations increases, resulting in an increase in overhead.
  • Because the number of segments increases, the amount of locked resources also increases when a table is deleted or all rows are deleted from a table.
Per-cent-age of free space in segmentSpecifiedWhen 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.14.2.2
Set to 0The 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 lengthPercent-age of unused space in page specified
  • If a row becomes longer as a result of UPDATE statement processing, and the contiguous free space is longer than the updated row, the corresponding line fits in the page.
  • When rows are added repeatedly by the INSERT statement, rows can be added until the page located close to the cluster key value becomes full.
For a table with the FIX attribute, storage efficiency is poor.14.3.2
Percent-age of unused space in page set to 0For 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 reusageUsed
  • Free space in the used segments can be used effectively.
  • The performance of free space search after the RDAREA is full is improved.
If there is insufficient free space for reuse, the overhead for free space search increases.14.5
Not usedIf 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 RDAREAUsedIf 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.14.6
Not usedDeadlock 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.
Temporary table RDAREAUsedTemporary tables can be used to perform complex data processing, as well as for executing transactions and SQL sessions without being affected by other users. Temporary tables do not require postprocessing.There is overhead for initializing a temporary table RDAREA when HiRDB starts or when the first INSERT statement is executed on a temporary table.14.7
Not usedThere is no overhead for initializing temporary table RDAREAs when HiRDB starts.When intermediate processing results are stored in a table during complex processing, postprocessing is required (such as deleting data after completion of processing).

Table 14-2 Maximum and minimum values for RDAREAs

ItemMaximum and minimum values
Total number of RDAREAs3 to 8,388,592
Number of master directory RDAREAs1
Number of data directory RDAREAs1
Number of data dictionary RDAREAs1 to 41
Number of user RDAREAs1 to 8,388,589
Number of data dictionary LOB RDAREAs1 to 2
Number of user LOB RDAREAs0 to 8,388,325
Number of registry RDAREAs0 to 1
Number of registry LOB RDAREAs0 to 1
Number of list RDAREAs0 to 8,388,588
Number of HiRDB files per RDAREA1 to 16
Number of base tables per RDAREA0 to 500
Number of indexes per RDAREA0 to 500
Number of lists per RDAREA0 to 50,000
Total number of HiRDB files1 to 134,217,728