These are some proactive steps that can be done on Database Maintenance
Thank you Hal for the guide.
Been avoiding the APM DB for sometime since it hasn't been a problem. But in order to be more proactive, wanted to take a look at any sort of information that might help if/when we do have an issue.
Had a question, within our postgresql instance there are quite a few ts_st_ts_all_dly_YYYYMMDD tables some dating to 2013 so it looks like two years worth. Also ts_st_ts_usgrp_wly_YYYYMMDD, ts_tran_comp_details_YYYYMMDD. What are these, are they important and is there a script that I could run or a configuration setting to reduce the amount of these tables?
We currently do not have TIMs and there appears to be no way to fully disable CEM, so the only data we (guessing) care about is the APM application map information.
If we found that there is a performance issue with our APM DB and we have configured CEM to the minimum values for defect/incident/events, is there a script or guidance on how to collapse/clear the CEM data?
What would be the draw backs from reinstalling postgresql, creating the schema and not importing any of the historic data into it? What would we lose if we are not running CEM?
Thank you,
Billy