Page Comparison

Mutual fund clients typically have daily NAV records to support their implementation. The dynamic return calculations fetch these NAV records, and dynamically revalue each day up through the end date of the performance period based on options set on the field. The audit logging process takes this a step further and actually writes each intermediate day's calculated values to the audit tables. This can result in a large volume of records being written to the database. In addition, when a fund/date combo is rerun, the process first needs to flush the old records before rewriting the new records.

It is also worth noting that overlapping performance periods for the same fund have unique data. This means that for 2 periods (1 year and 2 year ended 12/31/2005) each period has its own set of records (366 records for the 1 year and 732 records for the 2 year period). The second year of the 2 year period is not the same as the recent 1 year period.

The grids in the following table are meant to provide an idea of the volume of data that can be produced.

The number of records grow every time you run the process for a new effective date. For example, if you run the process described in the previous table for 10 days in a row, you have approximately 59,810 audit records per fund.

The following table shows an example field rule (not recommended).

The example in the previous table is an extreme case of what can happen if you attempt to log numerous fields for many funds. The fields are common for year end performance reporting but not necessarily for auditing. For example, there are three separate 1 year fields. Each would result in 366 audit records per fund, per effective date.

If you logged all fields for a representative set of 200 share classes, it would result in approximately 5.7 million audit records per effective date. This is not a recommended workflow.

As noted earlier you can configure the data archive engine to help manage database sizing.