Need to Clear Data From System Tables - Safe?

Need to Clear Data From System Tables - Safe?

  

Our DBAs have come to me to let me know that our OutSystems databases are getting out of hand, size-wise.  The two greatest offenders are:

OSUSR_70P_LOGEXTMETADATA (~170 gigs)
OSUSR_70P_LOGSTAGING (~50 gigs)


To my knowledge, these are OutSystems system-level tables, but they are wildly out of hand.  

1)  Is it safe to clear data from these tables?  Some of the records on LOGEXTMETADATA are from 2014 that we certainly don't seem to need (in our DEV environment, anyway, which is where this is largely happening).

2)  Boss thinks there's a DB Cleanup eSpace that can/should handle this, but I can't find it - does anyone know what he's talking about there?


Solution

Hello Chris,

That table doesn't actually seem to be a system table. Those are usually prefixed with OSSYS_ and not OSUSR_ (although there are some notable exceptions).

This table was probably created by one of your developers in a module. In order to identify which module those tables belong to, you can use the following SQL Query:

select ossys_espace.NAME
from ossys_entity
inner join ossys_espace on (ossys_entity.espace_id = ossys_espace.id)
where PHYSICAL_TABLE_NAME = 'OSUSR_70P_LOGSTAGING'


If this is indeed a table from your application, it is up to you to decide whether or not you can delete this data.


Regarding your second question, the forge component your boss meant was most likely DBCleaner, but that will not help you cleanup these particular tables, as it only deals with platform meta-data.

Solution

Hello Chris,

To check what tables are taking up space, and to what Modules and Applications they belong to, you can also use the DB Space tool.

Again, as Ricardo pointed out, these tools do not clean data form the tables, you need to get in touch with the responsible developers to understand what this data is and what deletion policy can be set up.

CA


Now that I know these aren't system tables, I found the application they were part of, which is now deleted.  So now we have a course of action - thanks!