Blue Prism audit tables and settings

#1
We are running Blue Prism 6.2 in a production environment. It has been in use for over 2 years. Our DBA informed me some of the audit tables are taking about 11 megabytes per row! He asked if there is a way we can purge the audit logs.

I looked at Blue Prism's tools and can see the Audit logs, but it doesn't appear you can erase these using Blue Prism's interface. I guess we'd need to use a tool like SQL Server Express to handle the delete?

How safe is it to have our DBA purge the tables? We would probably only need to retain the last 30 days or so. I don't want to purge records and find out we have wrecked some of our scheduled jobs.

I did not see a lot of options within Blue Prism to control the audit tables. It'd be nice to have a setting where it can clean up after a specified amount of time or allow the admin to specify what is saved in the audit tables.

Please share your thoughts on how your organization is handling the audit tables. Thanks!
 
#2
Running on version 6.5 here. We have 30 runtime resources (bots), running about 80 automations, so we generate a lot of audit logs, session logs, etc. My organization backs up the audit logs on a periodic basis, I believe it is monthly. After they are backed up, they are purged (but we do leave a couple of weeks' worth in the database). We also purge session logs and Studio backups, always leaving a couple of weeks' worth behind.

There has never been any issue with us doing this, although you won't be able to go back very far to compare Studio backups of processes and objects. Our fallback solution if we ever need to go back to look at any of these things would be to temporarily restore them to a new database environment. In the case of Studio backups, we always do full releases (rather than individual or ad hoc ones), so if we need to go back and see a process or object as of a date that is no longer in the database, we just import the release closest to the date we need into our Training database. We (developers) can do this ourselves.

Our SQL Server admins perform the backup and purge tasks in a standard maintenance window we have established weekly on the Sunday night overnight (i.e., early Monday morning), beginning at 3AM. I am not a DB admin, so I don't know for sure, but I believe there are BP tools available to the SQL Server admins to perform these backups and purges.
 
Last edited:
#3
Running on version 6.5 here. We have 30 runtime resources (bots), running about 80 automations, so we generate a lot of audit logs, session logs, etc. My organization backs up the audit logs on a periodic basis, I believe it is monthly. After they are backed up, they are purged (but we do leave a couple of weeks' worth in the database). We also purge session logs and Studio backups, always leaving a couple of weeks' worth behind.

There has never been any issue with us doing this, although you won't be able to go back very far to compare Studio backups of processes and objects. Our fallback solution if we ever need to go back to look at any of these things would be to temporarily restore them to a new database environment. In the case of Studio backups, we always do full releases (rather than individual or ad hoc ones), so if we need to go back and see a process or object as of a date that is no longer in the database, we just import the release closest to the date we need into our Training database. We (developers) can do this ourselves.

Our SQL Server admins perform the backup and purge tasks in a standard maintenance window we have established weekly on the Sunday night overnight (i.e., early Monday morning), beginning at 3AM. I am not a DB admin, so I don't know for sure, but I believe there are BP tools available to the SQL Server admins to perform these backups and purges.
Thank you for the detailed reply. It is helpful. Our management team needs to make some decisions on retention policies now.
 
Top