Question
CenturyLink
US
Last activity: 7 Jan 2022 1:54 EST
Pega Platform 7.4 - pr_history_data table retention
We are running Pega Platform 7.4 and the table PR_HISTORY_DATA has grown sizable.
Are there any retention settings that we can set to keep only 1 year or 6 months of data?
If not, is it safe to have our DBA delete records that are older without negatively impacting the system?
Thanks,
Brian.
Capgemini
IN
@BrianJ9608 - For your application specific history data you shouldn't use PR_HISTORY_DATA table but create dedicated history tables for different data classes. So, if you do that then PR_HISTORY_DATA will not get overburdened.
If you want to delete records from PR_HISTORY_DATA, you need to understand that it will erase whatever history records that have been stored so far and if you have used them for some kind of reporting it will definitely have an impact.
So, I would suggest the suggest
1. Check which class instances (history) is getting stored in PR_HISTORY_DATA.
2. For application specific classes, create dedicated history table and then move the data from PR_HISTORY_DATA to the dedicated table.
3.Delete the entries from PR_HISTORY_DATA.
CenturyLink
US
@Sudit Sengupta Thanks for the reply.
I have all of the reporting I need from the timeframe I want to remove from the table. So barring the impact to historical reporting, you are saying that having our DBA delete records from this table is safe? Do you know this firsthand, as in you have performed this action?
My concern was that removing records from the table directly via SQL could cause some foreign key errors that would crash the system or something.
If there is a way from within the platform to remove older records, I would be open to any suggestions there. Everything I found in documentation about setting retention periods referred to newer versions, not 7.4.
If anyone can else has purged older records from this table in this manner, I would appreciate hearing your experiences.
Thanks.
Capgemini
IN
@BrianJ9608 - I have done this (moving history records from PR_HISTORY_DATA to a dedicated table) for individual classes e.g. Data-Corr-Email and there were no impact.
For doing the same, you may even want to package such instances (using a product rule), change the mapping for the class and reimport. This way you don't need to write sql for moving records.
Once done, you can delete such class instances from pr_history_data