Clean-up Tracking
Description
Deletes tracking entities(Events, Jobs, Log entries, and Nodes) based on date of modification.
The activity attempts to delete all tracking entities that are older than a specified date/time and are in a completed state. Once the tracking entities are removed, the activity will also remove any Users that are marked for deletion.
Nodes can be excluded from deletion by setting the Retain property to True.
Assembly: iCore.Workflow.Activites
Category: iCPS
Arguments
| Name | Type | Description |
|---|---|---|
| Delete older than | TimeSpan | The activity will attempt to delete all tracking entities with a modification date earlier than this. |
| Batch timeout | TimeSpan | Specifies the maximum amount of time that a batch of deletions may take. If a batch is not completed within this time, the activity is aborted. |
| Batch size (Log) | Int32 | Specifies the number of Log entries to attempt to delete in each batch targeting the log. A larger number will result in longer batch times, but a too small number may lead to an increase in the total time required for the clean-up. |
| Batch size (Node) | Int32 | Specifies the number of Nodes to attempt to delete in each batch targeting Nodes. A larger number will result in longer batch times, but a too small number may lead to an increase in the total time required for the clean-up. |
| Batch size (Job) | Int32 | Specifies the number of Jobs to attempt to delete in each batch targeting Jobs. A larger number will result in longer batch times, but a too small number may lead to an increase in the total time required for the clean-up. |
| Batch size (Event) | Int32 | Specifies the number of Events to attempt to delete in each batch targeting Events. A larger number will result in longer batch times, but a too small number may lead to an increase in the total time required for the clean-up. |
| Batch size (Node data) | Int32 | Specifies the number of Node files to attempt to delete in each batch targeting Node data (Node files). A larger number will result in longer batch times, but a number too low may lead to an increase in the total time required for the cleanup. |
| Session lock timeout | TimeSpan | Specifies the maximum time to attempt to acquire a lock on the clean-up session. If a lock cannot be acquired within this time, the session is aborted. Before each batch, the activity will acquire a session lock on the database to ensure that only a single tracking clean-up session is active at any one time (the tracking clean-up is the only process associated with this lock, so it will not prevent any other part of iCore from accessing the database). The Session lock timeout argument specifies the maximum amount of time to wait for this lock to be acquired. During such a wait, the tracking clean-up is not performing any database activities, so it is normally safe to specify a very long timeout since it does not put any load on the database. |
| Batches between checkpoints | Int32 | Controls how often manual checkpoints are generated on the database during a clean-up session. If set to 0, no manual checkpoints are generated. If set to a positive value N, a checkpoint is generated between every N batches. In simple recovery mode, this may help prevent the database log to grow to a very large size during a cleanup session, but generating manual checkpoints too frequently may cause a significant slowdown of the clean-up and higher I/O on the database server. |
| Maximum total batch count | Int32 | Controls the maximum number of batches that the activity will run. If this number is exceeded before all entities are deleted, the activity will terminate. If set to 0 or left empty the number of batches are unlimited. |
| Maximum total duration | TimeSpan | Controls the maximum time that the activity is allowed to run. If this time is reached before all entities are deleted, the activity will terminate after the next batch. If set to 0 or left empty, no time limit is incurred. |
| Summary file | String | The full path to an XML file to which summary information and statistics will be written as the clean-up tracking session is executed. Can be left empty, if no summary file is desired. |
| Summary file detail level | Int32 | Only applicable if Summary file is set. If left empty or set to 0, no details are written. If set to 1, summary timing information about each batch is included. If set to 2, full details about each batch is included. If set to 3, some additional timing information is included. |
| Delay between batches | TimeSpan | The desired delay between two consecutive batches. In heavily loaded systems it can be useful to set a non-zero delay to give other processes more time to access the database. |
| Delay after deadlock | TimeSpan | Specifies the delay that will be applied after a database deadlock occurs before retrying the operation. |
| Result | ITrackingCleanupExecutionReport | An object containing a summary and statistics about the clean-up session. |
Remarks
For an entity to be deleted, the following conditions must be fulfilled:
- The entity must have a modification date before the specified date/time (argument Delete Older Than).
- The entity (as well as its children) must be in a final state. For example, a Job that has Succeeded but has a child Event that has not yet been processed will not be deleted.
Nodes with property Retain=True will not be deleted. Consequently, there may be Nodes in the system that exist without their creating Jobs. To delete these Nodes, the Retain property must be cleared before the activity is executed again. When a Node is deleted, all Node relations that point to that Node are deleted without any considerations.
The tracking clean-up process works by repeatedly deleting "leaves" in the entity tree, i.e. entities that do not have any children. It repeats this process until all viable tracking entities according to the configuration have been removed. For Events and Jobs that have hade children removed by Clean-up tracking, the entity property "Has cleaned children" is set to True.
note
The order in which the entities are deleted is undefined. If a tracking clean-up session is prematurely terminated there is no guarantee that only the oldest of the viable entities were deleted.
note
Performing tracking clean-up on a system with a large amount of tracking entities puts a heavy load on the database server which means executing the activity can take a long time. To avoid locking other processes out from the database, the activity runs in batches where each batch processes a smaller amount of entities within the same transaction. When performing tracking clean-up on a running system, we recommend setting a Delay Between Batches, which means that the clean-up will pause between each batch, thereby reducing database load and allowing the system to continue processing.
The size of each batch is directly determined by the Batch size argument for each respective tracking entity – it means the activity will consider up to (but no more than) the specified number of entities of the specified types.
We recommend generating a report file for the clean-up activity by
specifying a file name in the Summary file parameter. The schema for
this file is called TrackingCleanupReport20.xsd and can be
found in the <iCore installation directory\>\\Bin\\Config\\XML
Schemas folder (see iCIS directory structure). The summary file is
generated even if the tracking clean-up is cancelled. If a Summary file
detail level of 2 or higher has been specified, the summary file will
contain a lot of details about the timing and potential problems
associated with each batch. We recommend using a high detail level when
tuning or troubleshooting the activity.