RMAN Settings for Dedup

[Mike_Hoskins]

I'm working on adjusting filesperset for our Oracle RMAN backup script. The filesperset at 1 for the data files makes perfect sense. This will grow the catalog but the average size of the data involved and the unchanging nature of the majority in most tables makes this at least palitable. Then on the archived redo logs there seems to be differing thoughts. First is to also set this to 1. For max dedup again this makes sense. If the database is very busy this will grow the catalog dramatically, possibly to unacceptable levels. The other side of the coin is to go as high as 20 in some examples. Because of the transient nature of redo logs will only be archived so many times. I have read "since they don't dedup well" - maybe this is what that refers to? The log itself won't change obviously. But data files are generally long-lived structures. Thoughts? Did I miss something obvious?

[Mike_Hoskins]

Got thru to Support. The place he originally suggested starting from was four files per set for the archive logs. He asked how big our logs are. They are around 200MB - our DBAs feel they get better performance at that size for most of our databases. He altered his suggestion to start at 10 and move up and down from there in testing. That seemed to be to accommodate active databases without inflating the catalog size. It makes sense to keep the number of copies in the storage pool down since they probably will not dedup well in that configuration. Copies and longer term retention go to tape or other off site media. Using disk for long-term archiving would make for some interesting planning.

[Chad_Wansing2]

as far as the deduplication of your data goes, make sure you're using the "proxy copy" methodology of RMAN to make sure the data streams out of Oracle the same way every time and thereby getting better dedupe rates.

-Chad