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

From: Quanwen Zhao <quanwenzhao_at_gmail.com>
Date: Wed, 15 Nov 2023 23:17:15 +0800
Message-ID: <CABpiuuSfWLMONjK1roQvUoLNL1W8OppPYz1nLKWu0-B1C4N6Gw_at_mail.gmail.com>



Hello Stefan,

Sorry, I forget to mention my RMAN backup is no compression and I've checked all of the backup sets by v$backup_set_details that has a column compressed. BTW the Archived Log has just only 20 GB, so the datafile of rman backup is only 1300 - 20 = 1280 GB, 1280 >> 600 ?

Best Regards
Quanwen Zhao

Stefan Koehler <contact_at_soocs.de> 于2023年11月15日周三 22:51写道:

> Hello Quanwen,
> I guess you are referring to RMAN's unused block compression feature.
>
> Do you meet all requirements to make unused block compression kick in -
> see here "8.3.2.1 About Unused Block Compression":
> https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-backup-concepts.html#GUID-74FF41AF-D1EE-4DB1-AC0D-56FC83CAA91D
>
> Best Regards
> Stefan Koehler
>
> Independent Oracle performance consultant and researcher
> Website: www.soocs.de
> Twitter: _at_OracleSK
>
> > Quanwen Zhao <quanwenzhao_at_gmail.com> hat am 15.11.2023 15:14 CET
> geschrieben:
> >
> > 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
Received on Wed Nov 15 2023 - 16:17:15 CET

Original text of this message