Re: RMAN backup size is almost bigger twice than all of tablespace used size?

How are you calculating tablespace used space. According to the link that Stefan sent you should only be backing up (roughly) total file size - sum(dab free space) if you meet the conditions stated in 8.3.2.1

Pierre’s comments about backing up space from dropped objects are no longer completely accurate, and I don’t think the compressed column is the one to check for this ‘skip blocks’ mechanism, but check the compression_ratio. See https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/V-BACKUP_SET_DETAILS.html

Regards
Jonathan Lewis
(From my iPad mini; please excuse typos and auto-correct)

> On 15 Nov 2023, at 14:15, Quanwen Zhao <quanwenzhao_at_gmail.com> wrote:
>
> 
> Hello everyone!
>
> Recenty I've notice that there has oracle product system with 19.13, RMAN backup size is almost bigger twice than all of tablespace used size?
>
> Such as, all of tablespace used size is 600 GB and total size is 2500 GB, RMAN backup size (generated backup sets) is 1300 GB.
>
> Generally speaking, RMAN backup size is almost equal to all of tablespace used size.
>
> Firstly I suspect oracle recyclebin has occupied the massive data but the parameter recyclebin is off.
>
> Now I have to infer business tablespace has produced plenty of table fragments or HWM (High Water Mask) or discontinuous free data blocks.
>
> How to troubleshoot it for me? Any suggestion would be very appreciated!
>
> Best Regards
> Quanwen Zhao

--
http://www.freelists.org/webpage/oracle-l