The following type of user LOB RDAREA is excluded from reorganization time prediction:

• User LOB RDAREA that stores a plug-in index

Correct reorganization time prediction cannot be made in the cases explained below.

(a) When prediction data has not been collected correctly

For the facility for predicting reorganization time to be able to execute, at least four rounds of prediction data reflecting data storage status changes must have been accumulated. In addition, if prediction data is not collected regularly, it might not be possible to make valid predictions. For example, if prediction data is collected only for the first four days of the week in a system that is updated at the end of each week, valid predictions will not be forthcoming.

Reference note

The more regularly prediction data is collected, the higher the prediction accuracy becomes.

(b) Operation in which data storage status changes abruptly

Because HiRDB predicts future usage based on the historical record of the percentages of segments used in an RDAREA, it cannot make valid predictions if the data storage status changes abruptly. The following figure shows an example.

Figure 13-9 Example in which valid prediction cannot be made due to abrupt changes in the data storage status

Note: For the standard value, see 13.4.6 Customizing reorganization time prediction.

(c) When a table is stored in an RDAREA that does not have an optimum page size

When a table is stored in an RDAREA that does not have an optimum page size matching the table row length, reorganization time cannot be predicted correctly. For example, reorganization might be performed on a table that will not benefit from reorganization, or a reorganization instruction might be issued immediately following reorganization.

(d) Operation in which both the original RDAREA and a replica RDAREA coexist in the current RDAREA

Reorganization time prediction is targeted at the original RDAREA. A replica RDAREA is not the target of reorganization time prediction. Results of a command and SQL analysis for the replica RDAREA are not incorporated into the database state analyzed table or database management table. Therefore, correct prediction results cannot be computed if both the original RDAREA and the replica RDAREA coexist in the current RDAREA.

(e) Rebalancing table in which key values are not balanced

When you define a rebalancing table, you should select a hash function and a partitioning key that result in a uniform distribution of the data. If the key values are not balanced, too much data might be stored in a particular hash group (segment), and as a result, correct prediction will not be possible.

If a table satisfies all of the following conditions, the prediction is likely to call for RDAREA expansion:

• Variable-length character strings (VARCHAR, NVARCHAR, or MVARCHAR) are defined in the table.
• The no-split option is not defined for these variable-length character strings.
• The data was stored using a method other than by data-loading with the pdload command.

If a user-defined abstract data type (an abstract data type that is not provided by a plug-in) is defined for a table, reorganization by the pdrorg command or release of free pages being used by the pdreclaim command cannot be executed. Consequently, no reorganization instruction will be issued. If an RDAREA contains only such a table, only an RDAREA expansion or re-initialization instruction can be issued.

If a variable-length character string (VARCHAR, NVARCHAR, or MVARCHAR) whose actual length is 255 bytes or less branches to another page (for example, the case in which data of 256 bytes or larger is updated so that it becomes 255 bytes or smaller), reorganization can cancel the branching and improve storage efficiency and access efficiency. However, because the data length information is not collected, it cannot be incorporated into the prediction.

In the case of a table that has the data type of variable-length character string for which NO SPLIT is not specified, if there is a large amount of data whose actual length is shorter than the page length, many pages with poor usage rate result even immediately after reorganization. As a result, customization by the standard value definition file becomes necessary.

When the dictionary table is reorganized, both the database state analyzed table and the database management table are also subject to reorganization. Reorganize these tables together with other dictionary tables. There is no need to reorganize only the database state analyzed table and the database management table.

Reference note

When a large number of tables and indexes are deleted, invalid areas are created in the indexes that are defined to improve access efficiency to the two tables. However, because these areas are reused when new tables and indexes are defined, there is no need to reorganize these areas if the data dictionary RDAREA has sufficient capacity.

In the case of prediction level 1, when there is only one resource in an RDAREA (for example, only a single table is stored in the RDAREA), prediction is made based on the information in the database state analyzed table and database management table. When there are multiple resources in an RDAREA, prediction is made based on the information in the database state analyzed table only. Therefore, prediction accuracy is higher in the first case than in the second.

The reorganization timing is predicted on the basis of the database's history. If the database is not restored after a failure to its most recent status (such as when the database is restored to the point where a backup was made), correct prediction cannot be achieved. In such a case, correct prediction can be obtained by resetting the base information for prediction. This is called resetting the accumulated condition analysis results. For details about resetting the accumulated condition analysis results, see the manual HiRDB Version 9 Command Reference.