Nonstop Database, HiRDB Version 9 Command Reference

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

13.2.2 Facility for changing check pending status forcibly

Organization of this subsection
(1) Overview of function
(2) Execution unit of the facility for changing check pending status forcibly
(3) Forced setting of check pending status
(4) Forced release of check pending status

(1) Overview of function

The facility for changing check pending status forcibly changes the check pending status; this facility does not check the integrity of referential constraints or check constraints. This facility provides two functions, forced setting of check pending status and forced release of check pending status.

Forced setting of check pending status
This function forces a table into check pending status. You specify -k set to use this function.
Forced setting of check pending status is used in the following cases:
  • The pd_check_pending operand value in the system definition was changed from NOUSE to USE and the integrity of referential constraints or check constraints is not clear.
  • In a system in which the pd_check_pending operand was omitted in the system definition, HiRDB was upgraded to version 07-03 or later and the integrity of referential constraints or check constraints is not clear.
  • Table manipulation by the user must be regulated temporarily.
  • Because a constraint violation was detected during integrity checking, the check pending status was released forcibly, the data resulting in the constraint violation during SQL execution was corrected, and now integrity checking is to be performed again.

Forced release of check pending status
This function forces a table into the non-check pending status (releases the check pending status). You specify -k release to use this function.
Forced release of check pending status is used in the following cases:
  • The check pending status needs to be forcibly released in order to resume operations, such as when there is no need to perform integrity checking because the user has confirmed the integrity of the constraints.
  • A row resulting in a violation of a referential constraint is to be corrected by using SQL statements to update or delete a referencing table's foreign key.
  • A row resulting in a violation of a check constraint is to be corrected using SQL statements.

(2) Execution unit of the facility for changing check pending status forcibly

The facility for changing check pending status forcibly can be executed by table to update all referential constraints and check constraints defined for a table, or by constraint to update only an individual constraint. When the inner replica facility is used to perform processing by table, you can execute the facility for changing check pending status forcibly by all generations to process the original RDAREAs and all generations of their replica RDAREAs, by generation to process only a single generation, or by the current RDAREA's generation to process the generation of the current RDAREA. When the facility is executed by constraint, it is executed by all generations.

When the facility for changing check pending status forcibly is executed, information about the check pending status in data dictionary tables changes. Table 13-21 Locations in data dictionary tables where check pending status changes (when the inner replica facility is not used) and Table 13-22 Locations in data dictionary tables where check pending status changes (when the inner replica facility is used) list the locations in data dictionary tables where the check pending status changes.

Table 13-21 Locations in data dictionary tables where check pending status changes (when the inner replica facility is not used)

Exe unit -c option spec Table constraint Locations in data dictionary table where check pending status changes
Ref const Check const SQL_TABLES table SQL_REFERENTIAL_CONSTRAINTS table SQL_CHEKS table
CHECK_PEND column CHECK_PEND2 column CHECK_PEND column CHECK_PEND2 column
By table Not applicable No Yes -- Y -- Y#1
Yes No Y -- Y#1 --
Yes Yes Y Y Y#1 Y#1
By constraint Ref const Yes No Y -- Y#2 --
Yes Yes Y -- Y#2 --
Check constraint No Yes -- Y -- Y#2
Yes Yes -- Y -- Y#2

Legend:
Exe unit: Execution unit
-c option spec: -c option specification
Ref const: Referential constraint
Check const: Check constraint
Y: Check pending status changes.
--: Check pending status remains unchanged (the current status is maintained).

#1
The check pending status of all referential constraints or check constraints defined for the table is changed.

#2
The check pending status of only the constraint specified in the -c option is changed.

Table 13-22 Locations in data dictionary tables where check pending status changes (when the inner replica facility is used)

Execution unit -c option spec Table constraint Locations in data dictionary table where check pending status changes
Ref const Check const SQL_TABLES table SQL_REFERENTIAL_CONSTRAINTS table SQL_CHEKS table
CHECK_PEND column CHECK_PEND2 column CHECK_PEND column CHECK_PEND2 column
By all generations, by generation, or by current RDAREA generation Not applicable No Yes -- Y -- Y#1
Yes No Y -- Y#1 --
Yes Yes Y Y Y#1 Y#1
By constraint Ref const Yes No Y -- Y#2 --
Yes Yes Y -- Y#2 --
Check const No Yes -- Y -- Y#2
Yes Yes -- Y -- Y#2

Legend:
-c option spec: -c option specification
Ref const: Referential constraint
Check const: Check constraint
Y: Check pending status changes.
--: Check pending status remains unchanged (the current status is maintained).

#1
The check pending status of all referential constraints or check constraints defined for the table is changed.

#2
The check pending status of only the constraint specified in the -c option is changed.

Table 13-23 Locations of table information in an RDAREA where check pending status changes (when the inner replica facility is not used) and Table 13-24 Locations of table information in an RDAREA where check pending status changes (when the inner replica facility is used) list the locations of table information in an RDAREA where check pending status changes.

Table 13-23 Locations of table information in an RDAREA where check pending status changes (when the inner replica facility is not used)

Execution unit -c option spec Table constraint Locations of table information in an RDAREA where check pending status changes
Referential constraint Check constraint Referential constraint status Check constraint status
By table Not applicable No Yes -- Y
Yes No Y --
Yes Yes Y Y
By constraint Referential constraint Yes No Y --
Yes Yes Y --
Check constraint No Yes -- Y
Yes Yes -- Y

Legend:
-c option spec: -c option specification
Y: Check pending status changes. If there is no target replica RDAREA, Y becomes --.
--: Check pending status remains unchanged (the current status is maintained).

Table 13-24 Locations of table information in an RDAREA where check pending status changes (when the inner replica facility is used)

Execution unit Const with -c option spec Table constraint Locations of table information in RDAREA where check pending status changes#2
Ref const Check constr Generation 0 (original RDAREA) Generation 1 (replica RDAREA) Generation n (replica RDAREA)
Ref const status Check const status Ref const status Check const status Ref const status Check const status
By all generations N/A No Yes -- Y -- Y -- Y
Yes No Y -- Y -- Y --
Yes Yes Y Y Y Y Y Y
By generation#1 N/A No Yes -- -- -- Y -- --
Yes No -- -- Y -- -- --
Yes Yes -- -- Y Y -- --
By current RDAREA generation N/A No Yes -- -- -- -- -- Y
Yes No -- -- -- -- Y --
Yes Yes -- -- -- -- Y Y
By constraint Ref const Yes No Y -- Y -- Y --
Yes Yes Y -- Y -- Y --
Check const No Yes -- Y -- Y -- Y
Yes Yes -- Y -- Y -- Y

Legend:
Const with -c option spec: Constraint with -c option specified
N/A: Not applicable
Ref const: Referential constraint
Check const: Check constraint
Y: Check pending status changes. If there is no target replica RDAREA, Y becomes --.
--: Check pending status remains unchanged (the current status is maintained).

#1: -q 1 is displays (generation 1).

#2: This applies to all RDAREAs that store the table (original and replica RDAREAs).

(a) By table

When the facility is executed by table, it changes all the defined referential constraints or check constraints. You specify the -t option to execute the facility by table.

You use execution by table in the following case:

When the inner replica facility is used, pdconstck can be executed by table as well as in the following units:

By all generations
Among all referential constraints and check constraints defined for the table, pdconstck changes the check pending status for all generations of the original and replica RDAREAs that store the table. The criteria are the same as for execution by table. You specify -q all to execute pdconstck by all generations.

By generation
Among all referential constraints and check constraints defined for the table, pdconstck changes the check pending status of the generation specified in the -q option for each constraint. You specify the target generation number in the -q option to execute pdconstck by generation.
You use execution by generation when you are changing the check pending status of a specific generation.

By the current RDAREA's generation
Among all referential constraints and check constraints defined for the table, pdconstck changes the check pending status of the current RDAREA's generations for each constraint. You omit the -q option to execute pdconstck by the current RDAREA's generation.
You use execution by the current RDAREA's generation in order to release the check pending status of only the current RDAREA's generation, such as when the table was placed in check pending status as a result of executing a utility such as pdload on the current RDAREA's generation.
(b) By constraint

The facility changes only one referential constraint or check constraint defined for the table. You specify the -c option to execute the facility by constraint. When the inner replica facility is used, pdconstck changes all generations of the original and replica RDAREAs that store the table.

You use execution by constraint in order to change the check pending status for an individual constraint.

(3) Forced setting of check pending status

This function places a table, constraints, and RDAREAs in check pending status.

(4) Forced release of check pending status

This function releases a table, constraints, and RDAREAs from check pending status. The setting (whether or not the check pending status can be released) depends on the execution unit of pdconstck and the check pending status of the table, constraints, and RDAREAs. The following provides the details for each execution unit.

(a) When the inner replica facility is not used

Forced release of check pending status by table
When pdconstck is executed by table, it unconditionally places the target table, constraints, and RDAREAs in non-check pending status.

Forced release of check pending status by constraint
When pdconstck is executed by constraint, it places the constraint specified in the -c option in non-check pending status. Depending on the check pending status of other constraints, the check pending status of the table or RDAREAs may not change. The table below shows the changes in the check pending status.

Table 13-25 Changes in the check pending status by constraint (forced release of check pending status)

Condition Check pending status (table and RDAREA)
A constraint that is not specified in the -c option is defined There is a constraint in check pending status No change
All constraints are in non-check pending status Non-check pending status
Only the constraint specified in the -c option is defined for the table Non-check pending status
(b) When the inner replica facility is used

Forced release of check pending status by all generations
When pdconstck is executed by all generations, it unconditionally places the target table, constraints, and RDAREAs in non-check pending status.

Forced release of check pending status by generation or the current RDAREA's generation
When pdconstck is executed by generation or by the current RDAREA's generation, it places the generation of the RDAREA specified in the -q option in non-check pending status. Depending on the check pending status of other generations of the RDAREAs, pdconstck places the table and constraints in non-check pending status. The table below shows the changes in the check pending status for table and constraint.

Table 13-26 Changes in check pending status by generation or by the current RDAREA's generation (forced release of check pending status)

Condition Change of check pending status
Check pending status of RDAREA whose generation is not specified in the -q option Table check pending status Constraint check pending status
There is a generation in check pending status No change No change
All generations are in non-check pending status Non-check pending status Non-check pending status

Forced release of check pending status by constraint
When pdconstck is executed by constraint (by all generations), the processing is the same as when the inner replica facility is not used.