7.5.6 Notes
- After reinitializing an RDAREA, you should make a backup copy of the expanded RDAREA, the master directory RDAREA, and the corresponding data dictionary RDAREA, using the database copy utility (pdcopy). For details about the database copy utility, see Chapter 18. Database Copy Utility (pdcopy).
- If an error occurs while an RDAREA is being reinitialized, the system does not restore the RDAREA. In this case, you must restore it, because its HiRDB files may have already been deleted or the database may have become corrupted during initialization.
- When reinitialization of an RDAREA terminates normally, the RDAREA is placed in command shutdown and closed status. Before using such an RDAREA, you need to use an operation command to place it in shutdown release and open status.
- If you change the number of HiRDBs or rename the HiRDBs, the system deletes the HiRDB files that are no longer used.
- The following describes the data stored in the RDAREA, the definition information, and the user's action after re-initialization.
- RDAREA containing a table
- All data in the RDAREA is deleted and only the table definition information is inherited. If the table is partitioned, only the data stored in the RDAREA subject to reinitializing is deleted. If the table has an index, the index key data corresponding to the deleted table data is also deleted, so that only the definition information is inherited. If the table is partitioned but its index does not correspond to the partitioning key, the index is placed in the unfinished status.
- If the table contains a LOB column, the corresponding LOB data is also deleted.
- If the table contains an abstract data type column, the system treats it as a regular table. However, if the table contains an abstract data type column with the LOB attribute, the system also deletes the data for the abstract data type column in the corresponding user LOB RDAREA.
- If the table has a plug-in index, the system also deletes the data for the plug-in index and inherits only the definition information.
- If the indexes and LOB columns of the table stored in the RDAREA that is subject to re-initialization are stored in another RDAREA, the RDAREA containing the indexes and LOB columns must be in shutdown release and open status.
- User's action:
After the reinitialization, restore the data using the database load utility, database reorganization utility, or a UAP. Note that a UAP cannot access the database if there is an unfinished index (a KFPA11879-E error). If this happens, take one of the following actions:
Either use the database reorganization utility (pdrorg) to reorganize the table with the index defined (batch index creation mode), or re-create the index.
Delete the table and the index data by initializing the table with the index defined (by executing the PURGE TABLE SQL statement).
- RDAREA containing an index
- All key data for the index is deleted from the RDAREA. If the data corresponding to the index exists in other RDAREAs, the index is placed in the unfinished status.
- User's action:
If the index is successfully initialized after the reinitialization process, you can use the index as is. If the index is in the unfinished status, take one of the following actions:
Either use the database reorganization utility (pdrorg) to reorganize the table with the index defined (batch index creation mode), or re-create the index.
Delete the table and the index data by initializing the table with the index defined (by executing the PURGE TABLE SQL statement).
Reinitialize the RDAREA that contains the table with the index defined. In this case, the RDAREA containing the index must be in the shutdown release and open status.
- User LOB RDAREA
- All LOB data in the RDAREA is deleted. However, data in the LOB column structure base table associated with this LOB data is retained as is. If data in the LOB column structure base table is retained, the LOB column is treated as data with a length of 0.
- User's action:
After the reinitialization, restore the database using the database load utility, the database reorganization utility, or a UAP.
- User LOB RDAREA storing a column of abstract data type with the LOB attribute
- All data in the RDAREA is deleted and the area becomes access-disabled. If a retrieval is made from the abstract data type column structure base table with the LOB attribute, the error message KFPA11891-E is output. This is because the abstract data type column structure base table with the LOB attribute (the part of a table containing an abstract data type from which all abstract data type data is removed) associated with the data remains undeleted.
- User's action:
To access the storage user LOB RDAREA for the access-disabled abstract data type column with the LOB attribute, take one of the following actions:
Initialize the abstract data type column structure base table with the LOB attribute (by executing the PURGE TABLE SQL statement) to delete data.
Execute the database load utility (pdload) in the creation mode (-d).
Reinitialize the abstract data type column structure base table storage RDAREA with the LOB attribute. In this case, the abstract data type storage RDAREA with the LOB attribute must be in the shutdown release state and open status.
- User LOB RDAREA storing a plug-in index
- All data in the RDAREA is deleted. After the reinitialization, the plug-in index is placed in the unfinished status. If an attempt is made to access an unfinished plug-in index, the error message KFPA11879-E is output.
- User's action:
Restore the plug-in index in the unfinished status by executing the database reorganization utility specifying the index re-creation option.
- If a KFPX24231-W message is issued during the reinitialization of a registry RDAREA, and the registry LOB RDAREA is not reinitialized, you need to also reinitialize the registry LOB RDAREA. After the reinitialization, you must re-register the registry information used by the plug-in.
- If you have created a list on the basis of a table stored in the RDAREA subject to reinitialization, re-create the list.
- If the RDAREA to be re-initialized stores a referenced table, referencing table, or check constraint table, the check pending status is changed. The check pending status is managed by the data dictionary tables and the table information in the RDAREA. During re-initialization of the RDAREA, the check pending status is changed as described below. For details about the check pending status, see the manual HiRDB Version 8 Installation and Design Guide.
- When an RDAREA storing a referenced table (a table in which a primary key has been defined) is re-initialized, any table referencing that table (that is, a table in which a foreign key referencing that primary key has been defined) in other RDAREAs is placed in check pending status. If the RDAREA to be re-initialized is a replica RDAREA, a referencing table stored in the same generation of the target RDAREA that is to be re-initialized is placed in check pending status. If the value of the pd_check_pending operand in the system definition is NOUSE, the tables are not placed in check pending status. When an RDAREA to be re-initialized stores only indexes for the primary key, the check pending status remains unchanged.
If the system was unable to place the referencing table in check pending status, it displays the KFPX24242-W message. In such a case, possible causes are as follows:
The RDAREA storing the referencing table is in shutdown status.
The referencing table to be placed in check pending status is being accessed by another program.
There was no RDAREA with the same generation when the replica RDAREA was re-initialized.
Another I/O error or RDAREA access error occurred.
If this message is displayed, eliminate the cause of the error and set the check pending status forcibly.
- If an RDAREA storing a referencing table is re-initialized and the referencing table is in check pending status, the check pending status is released. However, in the following cases, only the table information in the RDAREA is released from check pending status; the data dictionary table is not released from check pending status:
The referencing table is partitioned.
The RDAREA storing the referencing table uses the inner replica facility.
The value of pd_check_pending in the system definition is set to NOUSE.
If the data dictionary table has not been released from check pending status, use pdconstck to perform integrity checking and then release the data dictionary table from check pending status.
- If an RDAREA storing a check constraint table is re-initialized and the table for which check constraints have been defined is in check pending status, the check pending status is released. However, in the following cases, only the table information in the RDAREA is released from check pending status; the data dictionary table is not released from check pending status:
The table for which the check constraints have been defined is partitioned.
The RDAREA storing the table with the check constraints defined uses the inner replica facility.
The value of pd_check_pending in the system definition is set to NOUSE.
If the data dictionary table has not been released from check pending status, use pdconstck to perform integrity checking and then release the data dictionary table from check pending status.
- If you are re-initializing an RDAREA to which the inner replica facility is applied (original and replica RDAREAs), the HiRDB file system area of the specified HiRDB file must have been registered to the corresponding generation.
- If you are re-initializing a replica RDAREA, an error results if there is no replica RDAREA generation that is associated with the table, index, and LOB column in the RDAREA to be re-initialized.
- If you are re-initializing an RDAREA to which the inner replica facility is not applied, specify a HiRDB file in the HiRDB file system area whose generations are not managed.
- Do not re-initialize an RDAREA that contains a table that is subject to data extraction during data linkage. If such an RDAREA is re-initialized, subsequent HiRDB Datareplicator linkage becomes invalid.
- An RDAREA containing a falsification prevented table cannot be re-initialized.