Nonstop Database, HiRDB Version 9 System Operation Guide

[Contents][Index][Back][Next]

13.2.4 Before reorganizing a table

Organization of this subsection
(1) Reorganizing a table in which a LOB column is defined
(2) Reorganizing a table in which an abstract data type is defined
(3) Reorganizing a table containing a large quantity of data
(4) Reorganizing a table in an RDAREA that is full
(5) When HiRDB Datareplicator is used to link data
(6) Creating an unload data file in a character special file
(7) Size of the file used during reorganization
(8) After reorganization has been completed

(1) Reorganizing a table in which a LOB column is defined

A LOB column structure base table and the LOB data can be reorganized at the same time. It is also possible to reorganize only the LOB column structure base table or only the LOB data. To reorganize at the same time both a table in which a LOB column is defined and the LOB data, we recommend that the -j option be specified in the pdrorg command.

(2) Reorganizing a table in which an abstract data type is defined

Not all tables in which an abstract data type is defined can be reorganized, as the following table shows.

Table 13-1 Reorganizability of a table in which an abstract data type is defined

Condition Reorganizability
Abstract data type provided by a plug-in Without LOB attribute Can be reorganized.
With LOB attribute Only column structure base tables of abstract data type can be reorganized.#
User-defined abstract data type Can be reorganized.

#: If the plug-in has the UNLOAD facility or the constructor parameter reverse generation facility, the entire table can be reorganized by specifying the -j option.

(3) Reorganizing a table containing a large quantity of data

When a table containing a large quantity of data is to be reorganized, you must consider whether reorganization with synchronization points set should be executed.

Normally, while a table is being reorganized, transactions cannot be reconciled until storage processing of all the data has been completed. This means that synchronization point dumps cannot be obtained during execution of the database reorganization utility. If HiRDB terminates abnormally during reorganization of a large quantity of data, it will take a long time to restart HiRDB. To resolve this problem, you can set synchronization points at intervals of any number of data items during storage of the data (reload processing) in order to reconcile transactions. This is called reorganization with synchronization points set.

Furthermore, when the log acquisition mode or the pre-update log acquisition mode is used as the update log acquisition mode for the database, if the utility terminates abnormally during reorganization with synchronization points set, data loading restarts with the data following the last data that was committed immediately before the abnormal termination. Therefore, processing time can be shortened.

To perform reorganization with synchronization points set, you must specify a synchronization point lines count, which is the number data items to be stored before a synchronization point is set. This value is specified in the option statement of the database reorganization utility.

Note
  1. Use of this facility reduces processing efficiency because synchronization point processing is also executed.
  2. If the utility terminates abnormally, the error handling that will be required will depend on the timing of the termination; for the error handling methods, see 20.18 When a utility terminates abnormally during execution of a reorganization with synchronization points set.
  3. If a table is row-partitioned into multiple back-end servers, you should consolidate the unload data files (by specifying the -g option in the database reorganization utility). If this is not done, the error handling should the utility terminate abnormally will become quite complicated; for details, see 20.18.3 Actions to be taken when a utility terminates abnormally before unload data files have been consolidated (HiRDB parallel server configurations only).
  4. Because data is stored on a new page for each synchronization point, the number of pages needed for storing data is greater than would be the case if this facility were not used. Therefore, do not use this facility to reorganize a table that is full. If it is used in such a case, a space shortage might cause an error in the database reorganization utility.
  5. Reorganization with synchronization points set cannot be performed on falsification prevented tables.

(4) Reorganizing a table in an RDAREA that is full

The value specified in the PCTFREE operand of CREATE TABLE is used as the percentage of unused space to be left in each page when a table is reorganized. Therefore, if a table in an RDAREA that is full is reorganized, an RDAREA space shortage might occur during table reorganization. To prevent this, you should specify the tblfree and idxfree operands in the option statement of the database reorganization utility (pdrorg command), and change the percentage of unused space per page specified in the PCTFREE operand of CREATE TABLE.

You use the tblfree operand to specify a percentage of unused space in the table, and you use the idxfree operand to specify a percentage of unused space in its indexes.

It must be noted that these are temporary measures that are used when an RDAREA cannot be expanded immediately before table reorganization. In preparation for data updating, you should use the database structure modification utility (pdmod command) to expand the RDAREA so that reorganization can be performed within the value specified in the PCTFREE operand of CREATE TABLE.

(5) When HiRDB Datareplicator is used to link data

When the database reorganization utility is executed on an extracted database, n or p should be specified in the -l option (which specifies execution of the database reorganization utility in the no-log mode or the pre-update log acquisition mode).

When the database reorganization utility is executed in the log acquisition mode, only some of the update information is transferred from the extracted database to the target database, thereby losing conformity between the two databases.

(6) Creating an unload data file in a character special file

To create an unload data file in a character special file, the character special file must be created in a HiRDB file system area for utilities. To do this, UTL must be specified in the -k option of the pdfmkfs command.

(7) Size of the file used during reorganization

If a message reporting a disk space shortage is output during execution of the database reorganization utility, even though ample disk space is available, the following are possible causes:

In this case, change the kernel parameter value. You can also avoid the problem by creating multiple unload data files. However, if the OS does not support large files, you must keep the disk partition size to 2 GB or smaller to be able to handle multiple files.

(8) After reorganization has been completed

If necessary, the optimizing information collection utility (pdgetcst command) should be executed after reorganization has been completed. For details about whether execution of the optimizing information collection utility is required, see the manual HiRDB Version 9 Command Reference.