13.19.6 Notes about linkage with related products
- When the inner replica facility is used
- If the referencing table in the original RDAREA is in check pending status, do not create an entity of the replica RDAREA. Cancel the check pending status of the referencing table in the original RDAREA and then create an entity for the replica RDAREA.
- When check pending status is set or canceled for all generations, the generations in command hold and in closed status are handled as not having an entity of the replica RDAREA. Therefore, these areas are excluded as targets for setting or canceling check pending status. If an RDAREA is excluded as a target for setting or canceling check pending status even though it has an entity, first cancel the hold status of the RDAREA and then use the integrity check utility to update the table information in the RDAREA.
- After executing the following operations, use the integrity check utility, specifying all generations to execute data integrity checking for each table.
PURGE TABLE statement
Re-initialize RDAREA
Delete replica RDAREA
Integrate inner replica group
- When performing updatable online reorganization
- Data integrity is not guaranteed when updatable online reorganization and database updating are performed in batch mode. This means that, if you have set USE in the pd_check_pending operand, the check constraint table might be in check pending status. In this case, use the integrity check utility to cancel check pending status. If NOUSE is specified in the pd_check_pending operand, use the integrity check utility to forcibly place the table into check pending status and then check data integrity. For details about how to check data integrity, see 13.19.5 Procedure for checking table integrity.
- Using HiRDB Datareplicator
When you use HiRDB Datareplicator, there is no need to define check constraints for a target table because only conforming data is applied.