Eagle Performance has three different types of tables in PERFORMDBO that should have a purge and archive strategy identified:
Audit tables track processing, but do not store data. You can purge or archive these tables based on how quickly they grow, and how far back you want to be able to look them up. The audit tables are described as follows.
This table stores the audit history of status changes made from the Commit Journal, or any time performance is committed as final. If you are going to purge or archive this table, you can do so by UPDATE_DATE so the most recent year or six months is available. If you archive, you can always get the data back if an audit question arises.
This table stores the audit history of any time performance is committed. If you are going to purge or archive this table, you can do so by UPDATE_DATE so the most recent year or six months is available. If you archive, you can always get the data back if an audit question arises.
This table stores the audit history of any time performance is committed using the Preliminary commit option named Only when materially different (Materiality Check Field), and contains total level PERF_SEC_RETURNS data. If the material change tolerance check results in data being overwritten, the previous total level return data for that entity is also written to this table. If you are going to purge or archive this table, you can do so by UPDATE_DATE so the most recent year or six months is available. If you archive, you can always get the data back if an audit question arises.
This table stores the audit history of feed updates from Autoperf, so you only have records here if you use Autoperf. If you are going to purge or archive this table, you can do so by UPDATE_DATE so the most recent year or six months is available. If you archive, you can always get the data back if an audit question arises.
Data tables store performance data. You can purge or archive these tables based on the multiperiod analysis you need to do. The data tables are described as follows.
This table stores the parent data records that represent each entity/date/source/model/frequency combination. You may be able to archive daily and monthly data for models that are not required for ad hoc time periods or longer time periods. Also, you may be able to archive security level records older than the current year.
This table stores the child data records related to each parent record in PERF_SUMMARY. You can use PERF_SUM_INST to archive any child records in this table that are related to an archived parent record in PERF_SUMMARY.
This table stores the data records for each entity that relate each security to a node in a performance model on a given date. This table should only be populated when a security changes a node, so it likely does not need to be purged or archived.
This table stores the data records for each entity that relate each security to that entity. This table should only be populated with one record for each security the portfolio has ever owned, so it likely does not need to be purged or archived.
The results tables are currently specific to Retail Fund Performance. You can purge or archive these tables based on the results you require. The data tables are described as follows.
This table stores the parent data records that represent each run of a Mutual Fund Performance (MFP) Audit report. The MFP Audit report is a Performance Analysis report with a Dynamic Mutual Fund field set to produce audit results. You can purge or archive any audit results you no longer require.
This table stores the child data records related to each parent record in MFP_AUDIT. Use AUDIT_ID to archive any child records in this table that are related to an archived parent record in MFP_AUDIT.
This table stores the child data records related to each parent record in MFP_AUDIT. Use AUDIT_ID to archive any child records in this table that are related to an archived parent record in MFP_AUDIT.
Add Comment