Interrupted Repack Threads

The database server can interrupt a repack thread for various reasons, including the following:

• The duration of the repack transaction has exceeded the Long Transaction limit.
• The coserver is shutting down.
• A user has invoked the FORCE_DDL_EXEC feature and issued a DDL statement that references the table that is being repacked. (See Forcing DDL Execution.)
• The database server is being reverted to an earlier version,

Repack requests are marked as interrupted (with "stopped" in the status column of the Data Repack Queue section of the output from the onstat –g pak command) under these additional circumstances:

• The RAW, OPERATIONAL, or STANDARD logging type of the table was changed after the repack request was queued but before the repack thread began processing the request. (After a repack thread opens a table, the logging type cannot be changed until after the repack operation is complete.)
• The REPACK_THREAD_MAX parameter was set to 0 by the onutil SET command.

If a repack thread is interrupted for any of these reasons, it does not rollback its work, but commits what it has done. In the case of a long transaction, the repack thread immediately commits its work, reduces its internal value of BATCHSIZE by half, and continues repacking. In all other cases, the interrupted transaction terminates after committing its work, and the onutil REPACK DATA command must be repeated to restart the interrupted repack thread.

For more information about command-line options of the onutil utility, see Appendix A. Syntax Summaries of Selected Utilities.