Configure the audit purge task
To configure the audit purge task, go to the task configuration page in the Services Framework user interface and select the New Task Configuration link.
| Field | Description | Example |
|---|---|---|
| Task | This field displays a list of all of the registered tasks. Select the name of the audit purge task that was entered during registration. | Audit Purge Task |
| Configuration | Descriptive name for the configuration. This field is required and can contain up to 60 characters. | Audit Purge Task |
| Description | A detailed description that explains what the configuration does. This field is optional. If entered, it must be 512 characters or less. | Purge all audit records older than 5 days. |
| Activate task | Identifies if the configuration is active. When it is active, the task is available to purge records. | Yes, No |
| Process end of day | Set this value to no because the task does not need to run at the end of the day. | No |
| Process cleanup | Set this value to no because the task does not need to process cleanup. | No |
| Keep days | Represents how long to keep the audit records before they are purged from the database. The way that the task uses this field depends on whether the category field is specified and the operating system that the database is running on. | For more information about how this field is used, see Purging records by using business day partitioning and Purging records by using the category field. |
| Commit rate | The maximum number of records to delete before a database commit is done. The commit rate is used only when the category field is specified or when your database is running on z/OS®. | If the commit rate is set to 500, the purge process does a database commit after every 500 audit records deleted. |
| Category | Category is used to limit purging based on the specified value. If no value is specified
for this field, business day partitioning and the operating system that the database is running on is used to
determine how the purge is done. This field is optional. The valid categories are shown in the following list:
|
For more information about how the task uses this field, see Purging records by using business day partitioning and Purging records by using the category field. |
| Query size | The maximum number of records to purge per query. The query size is used only when the category field is specified or when your database is running on z/OS. | If the query size is 100,000, the purge process fetches 100,000 entries per query. |
Purging records by using business day partitioning
When the category is not provided as a configuration field to the task, it indicates that the task is to use business day partitioning to purge records from the database.
- Databases that are on z/OS.
- Business day partitioning is not available for these databases. The purge process subtracts the keep days
field, which is a number of calendar days, from the date and time that the task runs to determine which
records to purge. Any record that is older than this calculated date is purged.
For example, the task is scheduled to run on 28 February 2020 at 8:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 29 February 2020 at 1:00 AM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 27 February 2020 at 1:00 AM Coordinated Universal Time. Because business day partitioning is not used, the task purges all data that is older than 27 February 2020 at 1:00 AM Coordinated Universal Time.
- Databases that are not on z/OS.
- Business day partitioning is available for these databases. The purge process subtracts the keep days
field, which is a number of calendar days, from the date and time that the task runs to determine which
records to purge. Depending on the time of day that the task runs, it might need to adjust the purge cut-off
date so that it doesn't purge a partial business day. The following examples show how the records are purged
in these types of databases.
- First example
- The task is scheduled to run on 28 February 2020 at 8:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 29 February 2020 at 1:00 AM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 27 February 2020 at 1:00 AM Coordinated Universal Time. Because business day partitioning is being used, 27 February 2020 at 1:00 AM cannot be used as the purge cut-off date because it is a partial day. To compensate for the partial day, the task includes one more calendar day as a keep day, which means the new purge cut-off date is 26 February 2020. The task then purges the older data one calendar day at a time, up to and including the data for 26 February 2020.
- Second example
- The task is scheduled to run on 28 February 2020 at 4:00 PM EST and its keep days field is set to 2. The task first converts its run date and time to Coordinated Universal Time, which is 28 February 2020 at 9:00 PM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 26 February 2020 at 9:00 PM Coordinated Universal Time. Because 26 February 2020 at 9:00 PM is a partial day, the purge cut-off date is moved back by one calendar day to 25 February 2020. The old data is purged one calendar day at a time, up to and including the data for 25 February 2020.
Purging records by using the category field
When the category is provided as a configuration field to the task, business day partitioning is not used to purge records from the database. The category and the keep days fields are used to determine which records are purged from the database. The operating system that the database is running on does not affect how the records are purged.
For example, the task is scheduled to run on 28 February 2020 at 8:00 PM EST, its keep days field is set to 2, and its category field is set to STATUS_CHANGE_EVENT. The task first converts its run date and time to Coordinated Universal Time, which is 29 February 2020 at 1:00 AM. The task then subtracts the two calendar days from the new date, which makes the purge cut-off date 27 February 2020 at 1:00 AM Coordinated Universal Time. Because business day partitioning is not used, the task purges all of the data that is for the STATUS_CHANGE_EVENT category and is older than 27 February 2020 at 1:00 AM Coordinated Universal Time.