Growth and significance of BPA Session Logs

[DominikBöhler]

I receive information from our database adminstration team that on a database to BP the table called "BPA Session Logs" is growing very fast (about 2 GB within a day).   First of all there is no need to get nervous (enough space is available), but the following questions arise: - What information does this table carry? A first look shows statistical data like "start launch application time", etc. - In what way do you (the community) use this table in-/directly? - Will this table be cleared / reduced automatically or is it necessary to do it manually (via BP GUI or DB Admin) to avoid too much growth of the database?   Thanks in advance for helping. Best Regards Dominik

[coreydrees]

The session logs carry all the logs from the processes, and they do grow very fast. So fast that blue prism tells you to not log so much.   Pretty ridiculous in my opinion.

[david.l.morris]

The session/process logs has very useful information for troubleshooting, but as corey mentions the table can grow super quickly (the audit log table does too). You can set the BP environment to archive the logs older than a certain time frame (1 week, 1 month, etc). Take a look in the System tab > System group > Archiving. If you've never done this before, it'd be a good idea to use manual mode to archive pieces of it first rather than doing it all at once.

[DominikBöhler]

Thank you corey and david, I will have a look at the mentioned function of archiving. Best Regards.

[MarshallMclane]

They advised us to scale back our loggging and to only keep about a month or less of logs in the database. I wish the database could handle more, it makes trouble shooting and historical info very difficult. 

[BenKirimlidis]

I experienced similar issues, however in our case, there were nested loops in a production automation and all events were being logged. Excessive logging can also create significant reductions in performance as the run time resource is constant writing to the DB. A single automation was logging ~100-200 megabytes of data per minute and filling our server very quickly. We changed this to log errors only across the whole process, and manually turned on logging only for important points which were useful for debugging problems. Once we corrected this oversight, we saw an almost 4x improvement in process times with the added benefit of the server not crashing all the time. We corrected this across all process and saw significant improvements, in one case we cut a process from 2-3 hours to 5-6 minutes. Recommend logging all data in QA / testing but as soon as the process goes into production, log the bare minimum to prevent excessive growth of the logs.

[Martynas]

Exacly what Ben wrote - single loop could grow your database by multiple GBs/day. What's more infuriating - automated archiving (or deletion of logs: https://portal.blueprism.com/system/files/2017-11/v6%20Data%20Sheet%20-… ) via Blue Prism itself might fail if there's lots of data (I've found out treshhold to be 1~2GB/day) and you'll need to run maintenance/upkeeping scripts directly in database. I just can't find those in the portal. Maybe someone from BP could share those?