To set up event purging for CA DataMinder machines, you must edit settings in the relevant machine policy.
To schedule regular purges, edit these settings in the Data Management folder of the local machine policy.
Confirm or reset this setting. It defaults to 1095 days, ensuring that the next purge removes all items more than three years old. Typically, but not always, this means events that have been retained in the local database for more than 1095 days and which have already been replicated.
Note: You can override this default minimum retention period in the user policy. Each capture and control trigger can specify a custom retention period for all events captured by that trigger.
By default, this is set to zero. Reset this to one day to schedule daily purges.
Specify at what time the purge runs. Particularly for gateways, you may want to run purges when there is little or no user activity to minimize the impact on machine performance. To specify the purge time, enter the number of minutes after midnight (local time). For example, enter 180 to specify a 3 a.m. purge. By default, this setting corresponds to 1 a.m.
Note: If you are editing the Common Client or the Common Gateway policies, you can enforce a setting for all client machines and gateways by clicking Enforce Items.
The following settings provide further control over purge operations:
You can choose whether to suspend the infrastructure during scheduled purges. Select this setting (set it to True) to automatically suspend the infrastructure while the scheduled purge runs (unless the infrastructure is already suspended).
Typically, you may want to suspend the infrastructure while performing other purge-related database activity or for performance reasons. For example, purging may be faster with foreign key constraints removed from certain tables. In this situation, we recommend that you pause replication activity while the purge runs to prevent new data being written to the database while these constraints are removed; suspending the infrastructure guarantees that all replication activity is paused for the duration of the purge.
When purging a database, CA DataMinder can delete a batch of rows in a single operation. You can specify how many rows are included in each batch deletion. Larger batch sizes mean bigger database transactions and more DBMS locks. Note that a single purge operation typically includes multiple batch deletions.
Note: This setting applies only to the default purge process. It may not apply to custom purge processes.
You can specify the maximum number of database rows that can be stored in a temporary table at one time.
For efficient purge processing, CA DataMinder retrieves events flagged for purging and stores them in a temporary database table. When the temporary table has been fully purged, CA DataMinder refills it with the next batch of events flagged for purging. This process repeats until the purge completes or times out. This setting prevents the temporary table becoming too large and adversely affecting performance.
Note: This setting applies only to the default purge process. It may not apply to custom purge processes.
In addition to specifying when a purge starts, you can also specify the maximum time (in minutes) that a database purge can run for. You may want to limit the purge duration so that, for example, it does not coincide with replication or import operations. When the timeout expires, the purge is terminated.
|
Copyright © 2014 CA.
All rights reserved.
|
|