select type, status, filename, buffer_size, buffer_count from v$backup_async_io where type <> ‘AGGREGATE’and status = ‘IN PROGRESS’;
Let’s use the concepts and play with MAXSETSIZE, MAXPIECESIZE, FILESPERSET, SECTION SIZE, MAXOPENFILES.
For the examples, I will use the following database:
MAXSETSIZE
Defines the maximum size of a backup set. The default MAXSETSIZE for a database is unlimited.
For the example above, if I put the MAXSETSIZE to 1019M, the backup fails:
But if I change the MAXSETSIZE to 1020M, the backup will run:
Why? Because one datafile cannot never be placed in more than one backup set (I’ve already told that in the theory section).
If I limit the size of a backup set to a value lower than my biggest datafile, it won’t fit there.
So, remember, that MAXSETSIZE should be at least as large as the largest datafile.
MAXPIECESIZE
Defines the maximum size of a backup piece. The default MAXPIECESIZE is unlimited.
When it is set to default, your backup set is usually stored in 1 backup piece (if to disk, this means one file per set).
Let’s run a simple backup and check:
As you can check above, simply running “backup database” with all the default configuration will create one backup set with all the datafiles, stored in a single backup piece, and another backup set with the spfile and control file in another single backup piece.
Now let’s change the MAXPIECESIZE to 50M and simulate the backup of one tablespace:
So here we have one backup set composed of 3 backup pieces (files). Why would you ever do this?
This is useful if you cannot create backup files bigger than X bytes due to restrictions of your OS or you want to move it to several media disks that have a size limit. It can also be a limit imposed by your media manager software.
FILESPERSET
Specify the maximum number of files in each backup set. The FILESPERSET default is 64.
The real number of files in each backup set is the minimum of the FILESPERSET setting and the number of files read by each channel.
So if you are backing up only 2 datafiles, and filesperset is 3, you will have only 2 datafiles in your backup set. Otherwise you are a wizard.
Let’s change the filesperset to 2 and test:
As you can see above, each backup set has now only 2 datafiles.
SECTION SIZE
It is useful when you want to enable RMAN channels to back up a single large file in parallel. RMAN divides the work among multiple channels, with each channel backing up one file section in a backup piece. Backing up a file in separate sections can improve the performance of backups of large datafiles.
If you specify a section size that is larger than the size of the file, then RMAN does not use multisection backup for the file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.
You cannot specify SECTION SIZE in conjunction with MAXPIECESIZE. Why?
Because if you have a datafile like my SYSAUX of 1020M and defines SECTION SIZE of 100M with parallelism of 4, this means that each backup thread will read 100M / 1020M. So it will be read 11 times in parallel by those 4 threads. Each thread will generate one backup piece.
The idea of MAXPIECESIZE is to limit a backup piece to a size. This error would appear if I mix the 2 commands (note that MAXPIECESIZE is still in the default configuration):
When you use SECTION SIZE and run any kind of backup, each generated backup set will have only one database file.
MAXOPENFILES
This defines the number of files that can be read simultaneously by each channel. The MAXOPENFILES default is 8.
If you set it to 1 or 8 and backup your database with a single channel, you will still have, as the first example, one backup set with all the datafiles, stored in a single backup piece, and another backup set with the spfile and control file in another single backup piece.
What will change is the distribution inside the backup set. With 1, as it will read one datafile at a time, it will write the backup data into the backup piece sequentially. With 8, the backup piece will have data from all the 8 datafiles mixed.
Let’s test it. I will run with MAXOPENFILES to 1 and RATE to 50 MB so the backup does not finish so fast.
While it is running, in another sqlplus screen I run:
As we can see it reads each datafile at a time.
Now with MAXOPENFILES set to 2:
Checking with sqlplus:
As we can see, now my rman channel is reading from 2 datafiles simultaneously. Thus, my level of multiplexing here is 2.
Remeber, in case files being backed up are ASM files, level of multiplexing may be reduced as ASM automatically takes care of the contention by striping the data. So a MAXOPENFILES of 5 does not necessarily means that you will have a multiplexing level of 5 when you backup to ASM.
External pages that helped in this article:
- http://oracleinaction.com/tune-rman-i/
- http://docs.oracle.com/cd/E11882_01/backup.112/e10642/glossary.htm#CHDHHBFC