Re: RMAN Backup Question - FILESPERSET

Your maxsetsize observation seems to be identical to what I've seen. I'm thinking that RMAN doesn't split datafiles - therefore your largest datafiles would always be backed up in one piece -- or speaking about incremental backups -- one piece contains all the changed blocks from one datafile (or more than one, but it won't split them up). I haven't verified or tested this - but from what I've seen happening - I *think* that's how RMAN handles it.

Can anyone confirm this ?

Stefan

On 1/25/07, Mark Strickland <strickland.mark_at_gmail.com> wrote:
>
> Oracle 10.1.0.5 on Solaris 9. Using block change tracking file and
> flash_recovery_area.
>
> The incremental level 1 backups of one of our databases produce a large
> number of very small backupsets, about 20K each. This causes the backup of
> the flash_recovery_area to tape to take around 4-1/2 hours whereas the
> backup to the flash_recovery_area beforehand takes around 15 minutes. There
> are 378 datafiles and many of them never get modified (old partitions). The
> backupsets appear to always have 3-4 datafiles and the backupsets for those
> never-modified files are very small. FILESPERSET is not set, but MAXSETSIZE
> is set to 6000M. There are four channels. I've pored over the manuals and
> Robert Freeman's fine RMAN book, along with Metalink and Google, and it
> seems there is conflicting information about the default value for
> FILESPERSET. In one place in the docs, it says that
>
> "The number of files to be backed up is divided by the number of channels.
> If the result is less than 64, then it is the number of files placed in each
> backupset. Otherwise, 64 files will be placed in each backupset."
>
> Robert Freeman appears to agree with that. In my case that would be the
> lesser of 378/4 or 64, so 64. In other places in the docs, it says that the
> default maximum number of files that will go into a backupset is 4. That
> pretty much matches what I'm seeing in my environment. I've been
> experimenting with FILESPERSET today in a test environment and I'm able to
> set it to different values and observe that the backupsets do contain that
> many files. Therefore, on Friday evening, I plan to change FILESPERSET to
> 64 in Production and run the incremental level 1 backup and see what
> happens. If it fails for some reason, I can easily re-run it with the
> default.
>
> Another oddity is that for our level 0 backups, we have MAXSETSIZE set to
> 10G but I see a few backupsets that exceed that size, like 20G. Not worried
> about that, just curious.
>
> Any insights?
>
> Regards,
> Mark Strickland
>
>

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