RMAN MAXPIECESIZE doesn't appear to be working

  • From: "Steve Wales (AddOns)" <steve.wales@xxxxxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 15 May 2020 01:01:01 +0000

I feel like I'm missing something.

Running a test on breaking down a backup into smaller pieces for loading into 
cloud based storage for a new offsite solution.

The request was to make the files in the backup be about 4.5GB (hence 4608M)

Running 18c Standard Edition / 18.10 Release Update / Linux 7 on OVM.

When I run the following:

run
{
allocate channel c1 device type disk;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 
'/backups/db1/ctl-%F';
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 4608M;
backup as compressed backupset incremental level=0 database tag db1_FULL format 
'/backups/db1/%d_%T_%s_%p_FULL';
}

My database (which has a total footprint of a little over 500GB) gives me 1 x 
66GB backup file.

I did try

Backup as compressed backupset section size 4608M ....

That gave me lots (LOTS!) of smaller files, most of them not even close to 
4.5GB.

I've read the relevant sections of the 18c Documentation and it seems to me 
that I've got the right options defined in the right place and doing to old 
Google search found several people who have tried the same thing and haven't 
had answers.

Someone suggested FILESPERSET > total number of datafiles, but the 
documentation indicates that if you don't specify filesperset  what the default 
formula is to calculate it and it should have worked.

So if anyone is able to tell me what I'm doing wrong and more importantly WHY - 
I'd appreciate the tip here.

Thanks
Steve

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived.

Other related posts: