When working with plans with larger participant counts (over 10,000 lives), group-level processing such as imports, snapshots, and exports take longer to process.

This is the result of many factors including the fact that DB Precision stores its data in a fairly complex relational database, as well as that it self-validates at different steps to help ensure the accuracy of both data and calculations.

The database that helps power DB Precision offers its users almost unlimited flexibility with its ability to store any type of information required for pension administration.

Unlimited numbers of things such as historical dates and amounts can be stored at any frequency. However, this flexibility requires multiple layers of queries and stored procedures to allow the system to properly assemble that information. In addition, all database activity must be logged in the transaction log which then adds additional work for the database server.

Although times will vary for different network configurations, when initially importing a typical 20,000 life plan, DB Precision will require about 10-15 minutes to read and analyze the file. Saving that data to the database will take another 40-120 minutes. The save of the initial import is by far the most time-consuming part when working with a large plan.

Imports beyond the initial import will also take longer to process. For example, importing a typical update file (such as for valuation) for a 20,000-life plan will take approximately 15 minutes for DB Precision to read and analyze and then another 10-20 minutes to then save that updated data to the database.

Although rare, should DB Precision fail during an import, users should reimport the same data by rerunning the import rather than trying to clear out the partially imported data. This will be much faster and more efficient.

In order to improve import performance, avoid using the option on import, "Display validation warnings for people imported", as this will add to the processing that must already be done. If desired, validations can then be separately run.

Running a snapshot for a large plan will also take longer to process. When DB Precision processes a snapshot, it is not only reading data from the database, but it is also determining items such as valuation status, participation dates, service amounts, normal retirement date, and any other calculated item specified by the user.

Processing a snapshot for a 20,000-life plan should take approximately 20 minutes to run. If the snapshot includes something such as an account balance that must be processed, the time will extend longer.

Export time will also vary but should take between 20 and 30 minutes to process.

The following can slow processing for any plan, but these issues will become more obvious when working with larger plans:

• Non-annual Reported Amounts: When amounts are reported more often than annual, such as monthly or bi-weekly, this can slow processing as DB Precision will need generally project these amounts far in to the future. One way to improve processing for such plans is to avoid projecting these amounts when possible (by specifying no projection for that Reported Amount in the Assumption Definition that is then used).
• Account Definitions: For plans that have Account Definitions, if the account's transactions are formula-based, this can slow processing. If possible, minimize referencing such Account Definitions in the plan's exports and snapshots.
• Formula Derived Item Overrides: If a plan has Service Definitions that use a Formula Derived Item override for service units, this can slow processing. This is because each unit (usually annual units) must have that formula evaluated for every service calculation. For projections, this can result in calculations not only being required in the past but also in the future. These overrides should therefore be avoided for large plans if possible.