If the number of transactions stored in the Enswitch database becomes excessive, performance may suffer. Billing may take a long time to run, and the transactions report may be slow. This can be cured by archiving old transactions.

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

Archiving transactions locally

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

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

This archives transactions older than 90 days every night at 3:39am.

Archived transactions are moved from the transactions to the transactions_archive table within the Enswitch database. This improves performance by reducing the size of the indexes on the transactions table, making the searches done by billing and the transactions report faster. Note that auxiliary table transaction_taxes is not touched as this is only ever accessed by primary key, so moving data out of it does not speed up access.

Archived transactions are hidden from all users by default. It is possible to allow some roles to access them by granting the "Read archived data" role permission. This should be done with caution because it reduces the performance gains made by archiving, and should normally be limited to the system owner role.

Archiving transactions remotely

As an alternative to archiving transactions locally as above, transactions (and the corresponding data from auxiliary table transaction_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 transactions locally, move them back to the transactions table.
4. Create the remote database, with the transactions and transaction_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 a database user for the new database, and give them access to the above tables.
6. Create "delete/transactions/archive", "insert/transactions/archive", and "select/transactions/archive" handlers in /etc/enswitch/databases.ini.
7. Change the "Table containing archived transactions" configuration setting to "transactions".
8. Restart the web server.
9. Create a crontab entry, similar to the local archiving above, but for "/opt/enswitch/current/bin/enswitch_transactions_archive_remote".
10. Run "/opt/enswitch/current/bin/enswitch_transactions_archive_remote <days>" manually.
11. Check that the data in both databases is as you expect.
12. Enable the "Read archived data" permission for any roles that may access archived transactions. This should be done with caution because it reduces the performance gains made by archiving, and should normally be limited to the system owner role.