If the number of CDRs stored in the Enswitch database becomes excessive, performance may suffer. Billing may take a long time to run, and the Reports » Call history menu may be slow. This can be cured by deleting or archiving old CDRs.

Warning: Do not delete or archive CDRs until you are certain that they are no longer needed for billing. Doing so may cause incorrect invoices to be produced.

Deleting CDRs

If old CDRs are no longer required, they can be deleted. To do this, add an entry similar to the following to /etc/crontab:

09 3 * * * enswitch /opt/enswitch/current/bin/enswitch_cdrs_delete 366

This deletes CDRs older than 366 days every night at 3:09am. enswitch_cdrs_delete deletes both archived (see below) and unarchived CDRs, plus their auxiliary data in the "cdrcosts" and "cdrcost_taxes" tables.

Archiving CDRs locally

If old CDRs are still required, for example for regulatory compliance, they can be archived within the Enswitch database. This improves the performance of billing and the Reports » Call history menu, but still makes the archived CDRs available to the system owner. To do this, change the "Table containing archived CDRs" configuration setting to "cdrs_archive", then add an entry similar to the following to /etc/crontab:

39 3 * * * enswitch /opt/enswitch/current/bin/enswitch_cdrs_archive 90

This archives CDRs older than 90 days every night at 3:39am. This can be done in conjunction with deleting CDRs, so (for example), CDRs could be archived after 90 days, then deleted after 366 days.

Archived CDRs may be searched by System Owner users only. It is possible to allow other users to do so using the "Call history (archived)" role setting, but this is not recommended because it reduces the performance gains made by archiving.

Archived CDRs are moved from the "cdrs" to the "cdrs_archive" table within the Enswitch database. This improves performance by reducing the size of the indexes on the "cdrs" table, making the searches done by billing and the Reports » Call history menu faster. Note that auxiliary tables "cdrcosts" and "cdrcost_taxes" are not touched as these are only ever accessed by primary key, so moving data out of them does not speed up access to them.

Archiving CDRs remotely

As an alternative to archiving CDRs locally as above, CDRs (and the corresponding data from auxiliary tables "cdrcosts" and "cdrcost_taxes") can be moved to a remote database on another machine. THIS IS NOT SUPPORTED, AND NOT RECOMMENDED. IF YOU DO THIS, YOU ARE RESPONSIBLE FOR CONFIGURING AND MANAGING THE REMOTE MACHINE. YOU WILL NEED TO MERGE ANY SCHEMA CHANGES MADE BY FUTURE ENSWITCH UPGRADES. If you're sure you want to do this, the steps are:

1. Contact Enswitch support and let them know you're doing this. They will disown any responsibility for what you're doing.
2. Take a backup of the Enswitch database.
3. If you've archived any CDRs locally, move them back to the "cdrs" table.
4. Create the remote database, with the "cdrs", "cdrcosts", and "cdrcost_taxes" tables. These tables must have exactly the same schemas as the Enswitch database. Note that if future versions of Enswitch change these schemas, you must manually change the remote database.
5. Create "delete/cdrs/archive", "insert/cdrs/archive", and "select/cdrs/archive" handlers in /etc/enswitch/databases.ini.
6. Change the "Table containing archived CDRs" configuration setting to "cdrs".
7. Restart the web server.
8. Create a crontab entry, similar to the local archiving above, but for "/opt/enswitch/current/bin/enswitch_cdrs_archive_remote".
9. Run "/opt/enswitch/current/bin/enswitch_cdrs_archive_remote <days>" manually.
10. Check that the data in both databases is as you expect.
11. Optionally, configure enswitch_cdrs_delete as above.