RMAN MAXPIECESIZE doesn't appear to be working

From: Steve Wales (AddOns) <"Steve>
Date: Fri, 15 May 2020 01:01:01 +0000
Message-ID: <CY4PR20MB1527A2899E27717E285816AAF1BD0_at_CY4PR20MB1527.namprd20.prod.outlook.com>

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:

allocate channel c1 device type disk;
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.



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.

Received on Fri May 15 2020 - 03:01:01 CEST

Original text of this message