In our application previously we were storing all our attachments in Pega DB which led to exponential growth of the pc_data_workattach table. So recently we have migrated all our attachments to external S3 repository in order to reduce the datatable size. We are using Oracle database. However pre/post migration when we tried to compare the size of the table using the below queries we noticed that with this query it shows that the table size have increased instead of decreasing which is impossible, as we have double checked pyAttachStream is no longer there in any records and all the attachments successfully exists in the repo and also readable/downloadable from there.

This lead us to believe that we might be using wrong query to get the size of the workattach table.  Can someone help out with this?

Queries used:

select OWNER,SEGMENT_NAME,BYTES/1024/1024 MB from dba_segments where owner='PEGA_DATA' and SEGMENT_NAME='PC_DATA_WORKATTACH';

For the above query prior to migration it gave value of 5536 and post migration 9160 (an increase which doesnot makes any sense)

Another query we tried:

SELECT segment_type, sum(bytes/1024/1024) AS gb FROM dba_segments WHERE (segment_name = 'PC_DATA_WORKATTACH' OR segment_name LIKE 'SYS_LOB%') AND owner = 'PEGA_DATA'

Can someone please help us out on how to get the actual size of the pc_data_workattach table? Although not related entirely but we checked the below article but didn't help us.