Forum Discussion

XaviC's avatar
XaviC
New Contributor III
2 days ago

Database space control policies

Hi!

We are trying to control the size increase in our production application. We know the growth comes from:

  1. Stage tables that allow users to drill down and back onto source data.
  2. Data records
  3. Audit tables (they can grow a lots if they are recording continuous changes to rules, data for example)
  4. Logs which will impact Framework database growth (task activity and error logs, will vary depending on the detail login set in BR, DM and on the system configuration as well as your retention policy)
  5. Load transactional data, which will increate your data units and data records unnececarily, which BIBlend should be used for this type of data load instead of loading it to the finance cube.

We have analyzed it and we realized the StageAttributeTable and other stage tables has a significant size. Has ayone performed databse maintenance by deleting data from the stage tables? Is it possible to do that while keeping the cube data intact and workflows completed?

Any ideas or best practices regarding database maintenance would be very welcome.

Regards,

Xavi

 

Infrastructure
Methodology

1 Reply

  • SimonHesford's avatar
    SimonHesford
    Contributor II
    14 hours ago

    The stage tables are not cube data so will not impact data in your application if you remove but will impact the ability to drill down. Therefore you may only want to retain the stage data for a period which it may be used e.g. the last 12 months. Similarly the Error Logs in OneStream can grow to a significant size depending on the level of debugging you have built into the application. This can be managed from the Error Log screen in the System tab which allows you to delete all records older than 30 days or you can set up a custom job schedule to manage this. It is also advisable in any Production application to ensure that the logging level is set to the lowest level necessary i.e. not Debug