Run the purge flow if you need to remove data from this tablespace - its used in conjunction with a few other tables. Removing data directly from this table without syncing across the rest of the relationship map will cause data lookup issues for reporting. 1M records really isnt that large for this table -- is there an issue occurring or just housekeeping? 

Thanks a lot JarodMB for your reply.

I wanted to empty this table because it takes more than 80GB and in our dev plateform we do not have a large disk space (~~ 100 GB).

NB: For the number of records, the screenshot previously attached is from our dev server, the prod one has more than 80 M records.

Regards;

Hello Adel,

How did you get the OO DB tables  size report (attached in screenshot). I wish to have the same one for our env.

Please do let me know.

Regards,

Hi Mhamed,

I am using SQL Server.

You choose your database -> right click -> Reports -> Standard Reports -> Disk usage by table 

Regards;

Thanks Adel,

We have an oracle database. May be i should see how can i fetch reports from oracle ..

Hi Adel,

What JarodMB said is correct the best way to delete data from the database is via the purge procedures. Now in case of emergency in environments where data retention is not important (dev / test evnironments) truncating tables is faster and cheaper (from the I/O perspective).

The step log bindings table contains the input, output and transition data for all steps of executed flows. This data is only persisted after a step is completely executed. If data is removed from this table then you might have issues seeing step details in the OO Central UI drilldown. Judging from the usage in the screenshot this looks to be a 10.20 range OO install which is really old at this point. While procedures do exist for MSSQL and 10.20 range, i think it would be safe to truncate the bindings table for a quick fix.

Hope this helps,

Vlad

For Oracle use (this includes LOB data also):

SELECT segment_name AS "Object Name", segment_type AS "Object Type", round(bytes/1024/1024,2) AS "Object Size (Mb)"
FROM USER_SEGMENTS
ORDER BY "Object Size (Mb)" DESC;