Check pending status is set on following situations.
1. When you use ALTER TABLE to add a check constraint to already populated tables, and CURRENT RULES special register is DB2®, the check constraint is added to the table description but its enforcement is deferred. Because there might be rows in the table that violate the check constraint, the table is placed in CHECK-pending status.
2. When a table is LOADed with ENFORCE NO option, then the table is left in CHECK PENDING status as DB2 bypasses referential integrity and check constraints
3. An index might be placed in CHECK-pending status if you recovered an index to a specific RBA or LRSN from a copy and applied the log records, but you did not recover the table space in the same list. The CHECK-pending status can also be set on an index if you specified the table space and the index, but the recovery point in time was not a point of consistency (QUIESCE or COPY SHRLEVEL REFERENCE).
To reset this status, run the CHECK DATA utility, which locates invalid data and, optionally, removes it. If CHECK DATA removes the invalid data, the remaining data satisfies all check and referential constraints and therefore, the CHECK-pending restriction is removed.
1. If a table space is in both REORG-pending and CHECK-pending status (or auxiliary CHECK-pending status), run the REORG TABLESPACE utility first and then run CHECK DATA to reset the respective states.
2.Run the CHECK INDEX utility on the index. If any errors are found, use the REBUILD INDEX utility to rebuild the index from existing data.
3.Use the REPAIR utility with the SET STATEMENT and NOCHECKPEND option.
1. When you use ALTER TABLE to add a check constraint to already populated tables, and CURRENT RULES special register is DB2®, the check constraint is added to the table description but its enforcement is deferred. Because there might be rows in the table that violate the check constraint, the table is placed in CHECK-pending status.
2. When a table is LOADed with ENFORCE NO option, then the table is left in CHECK PENDING status as DB2 bypasses referential integrity and check constraints
3. An index might be placed in CHECK-pending status if you recovered an index to a specific RBA or LRSN from a copy and applied the log records, but you did not recover the table space in the same list. The CHECK-pending status can also be set on an index if you specified the table space and the index, but the recovery point in time was not a point of consistency (QUIESCE or COPY SHRLEVEL REFERENCE).
To reset this status, run the CHECK DATA utility, which locates invalid data and, optionally, removes it. If CHECK DATA removes the invalid data, the remaining data satisfies all check and referential constraints and therefore, the CHECK-pending restriction is removed.
1. If a table space is in both REORG-pending and CHECK-pending status (or auxiliary CHECK-pending status), run the REORG TABLESPACE utility first and then run CHECK DATA to reset the respective states.
2.Run the CHECK INDEX utility on the index. If any errors are found, use the REBUILD INDEX utility to rebuild the index from existing data.
3.Use the REPAIR utility with the SET STATEMENT and NOCHECKPEND option.
Following jobs remove copy pending and recovery pending status from a table space and removes copy pending, recovery pending status and rebuild pending status from an index space
//STEPO1 EXEC PGM=DSNUTILB,REGIONM,
// PARM='DB2X,MIGRDAN, '
//STEPLIB DD DSN=XXX.XXXXX.SDSNLOAD,DISP=SHR
//SYSIN DD *
REPAIR SET TABLESPACE XXXXX.XXXXX NOCOPYPEND
REPAIR SET TABLESPACE XXXXX.XXXXX NORCVRPEND
REPAIR SET INDEX XXXXX.XXXXX NOCOPYPEND
REPAIR SET INDEX XXXXX.XXXXX NORCVRPEND
REPAIR SET INDEX XXXXX.XXXXX NORBDPEND
/*
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.