Purging history tables
During development and testing, it is common to load, clear frequently, and re-load data into Incentives tables, considerably more than production. Where History Tracking has not been disabled, these actions will result in the associated history tables growing excessively, consuming large amounts of storage space.
Impact on performance and solution
Extensive history tables can negatively affect import times, causing them to run slower.
The purge history feature can be used to mitigate this issue.
Scenarios for using the purge history tool
Audit history not needed
For all Incentives tables, which is common in non-production environments.
For specific Incentives tables, also common in non-production environments.
Restored models
When audit history is not needed in a restored model sourced from a database backup from another environment.
Archived data
When audit history is before a certain date, it is unnecessary due to the model being archived at that point in time.
Sensitive data
When sensitive data needs to be masked, purging the audit history can prevent unnecessary masking of history tables.
Post-purge optimization
After purging history, it is recommended to run the Model Optimize feature to update the statistics of the history tables, reflecting that they are now empty.
Scheduling and maintenance
Scheduling purges
History purging can be scheduled for any specified Incentives table.
Database maintenance
Purging history reduces the database footprint at the time of execution, but a database maintenance job is also recommended as history tables will gradually grow over time.
The maintenance job should rebuild indexes if fragmentation is high.
Index Reorganization: Perform when fragmentation is between 5% and 30%.
Index Rebuild: Perform if fragmentation exceeds 30%.
Index reorganization and rebuilds are part of the Scheduler, though fragmentation percentages are not yet visible through the admin web application. For further details, refer to the Index Reorganization and Rebuilds section.