.
PURGE
The PURGE control statement requests that the specified table be purged of all data with a datetime older than the specified value.
The following table describes the operands for the PURGE control statement.
Operand | Description |
|---|---|
TYPE=tableType | Specifies the type of table Possible values are:
This field is included only for compatibility with other control statements. In the present release it is for documentation only. |
TYPE2=auditTableType | Specifies the type of statistics or audit table Possible values are:
This required field has no default. |
TYPE3=statisticsTableType | Specifies the type of statistics table Possible values are:
This required field has no default. |
TYPE4=acceleratorSimBPTableType | Specifies the type of accelerator table or simulated bufferpool table Possible values are:
This required field has no default. |
TABLE=tableName | Name of the table to be processed This required field has no default. |
EXPDT=yyyy-mm-dd-hh:mm:ss | Timedate of the oldest entry that is to be kept All older entries are deleted. This operand is mutually exclusive with RETPD. |
RETPD=nnnD | Interval describing the oldest entry that is to be kept Any entry older than today minus nnn days is deleted. This operand is mutually exclusive with EXPDT. RETPD=0D deletes all rows in the selected table. |
COMMIT=number|0 | The number of records to be deleted before a COMMIT is issued COMMIT can be used to reduce lock contention during PURGE processing, however, PURGE processing will run longer, and might encounter lock contentions that further delay processing. The default value of 0 indicates that the COMMIT will be performed after the delete is done. This increases the length of time a lock is held, but is generally more efficient. |
Related topic