RMAN builds buffers in memory through which it streams data blocks for potential backup. This memory utilization counts against the total size of the PGA and, sometimes, the SGA. There are two kinds of memory buffers. Input buffers are the buffers that are filled with data blocks read from files that are being backed up. Output buffers are the buffers that are filled when the memory-to-memory write occurs to determine whether or not a particular block needs to be backed up.
When the output buffer is filled, it is written to the backup location. There is a difference in the memory buffers depending on whether you are backing up to or restoring from disk or tape.
Input Memory Buffers
When you are backing up the database, the size and number of input memory buffers depends on the exact backup command being executed. Primarily, it depends on the number of files being multiplexed into a single backup. Multiplexing refers to the number of files that will have their blocks backed up to the same backup piece. In order to keep the memory allocation within reason, the following rules are applied to the memory buffer sizes based on the number of files being backed up together:
If the number of files going into the backup set is four or less, then RMAN allocates four buffers per file at 1 MB per buffer. The total will be 16MB or less.
If the number of files going into the backup set is greater than four, but no greater than eight, then each file gets four buffers, each of size 512KB. This ensures that the total remains at 16MB or less total.
If the number of files being multiplexed is greater than eight, then RMAN allocates four buffers of size 128KB. This ensures that each file being backed up will account for 512KB of buffer memory.
Bear in mind that these memory amounts are on a per-channel basis. So, if you allocate two channels to back up a database with 32 datafiles, for instance, then RMAN will load-balance the files between the two channels and may not end up with 16 files per channel. If some files are significantly larger than others, you may end up with only 8 files going into one backup set and 24 files going into the other. If this were the case, then the buffers for the first channel with 8 files
would allocate 16MB of memory for input buffers (four buffers multiplied by 512KB each, multiplied by 8 files), and the second channel would allocate 12MB of memory buffers (521 KB per file multiplied by 24 files).
You can use the following query to monitor the size of buffers on a per-file basis while the backup is running:
SELECT set_count, device_type, type, filename,
buffer_size, buffer_count, open_time, close_time
FROM v$backup_async_io
ORDER BY set_count,type, open_time, close_time;
Output Buffers when Backing Up to Disk
In addition to input buffers, RMAN allocates output buffers, depending on what the output source is. If you are backing up to disk, then RMAN allocates output buffers that must fill up with data blocks from the input buffers before being flushed to the backup piece on your file system. Per channel, there will be four output buffers, each of which is 1 MB in size. So, the memory footprint per channel will always be 4MB.
Output Memory Buffers when Backing Up to Tape
Memory allocation is different when backing up to tape, to account for the slower I/O rates that we expect from tape devices. When you are backing up to or restoring from tape, RMAN allocates four buffers per channel process, each of which is 256KB in size, so that the total memory footprint per channel is 1 MB.
Memory Buffers on Restore
Memory utilization during restore operations is slightly different than during backups. This is due to the fact that the roles are reversed: instead of reading from the datafiles and writing to the backup location, we are reading from the backup location and writing to the datafiles. During a restore from a disk backup, the input buffers will be 1MB in size, and RMAN will allocate four buffers per channel. When restoring from tape, RMAN allocates four input buffers with a size of
BLKSIZE, which defaults to 256KB. The output buffers on restore are always 128KB, and there will be four of them per channel.
RMAN Memory Utilization: PGA vs. SGA
Backups to disk use PGA memory space for backup buffers, which is allocated out of the memory space for the channel processes. If your operating system is not configured for native asynchronous I/O, then you can utilize the parameter DBWR_IO_SLAVES to use I/O slaves for filling up the input buffers in memory. If this parameter is set to any non-zero value, RMAN automatically allocates four I/O slaves to coordinate the load of blocks into the input memory buffer. To coordinate this work, RMAN must utilize a shared memory location. So, the memory buffers for disk backups are pushed into the shared pool, or the large pool if one exists.
Memory for tape output buffers is allocated in the PGA, unless you are using tape I/O slaves. To enable tape I/O slaves, you set the init.ora parameter BACKUP_TAPE_ IO_SLAVES to TRUE. This can be done dynamically and set in the SPFILE if you desire. When this is set to TRUE, RMAN creates a single slave process per channel to assist with the backup workload. To coordinate this work, RMAN pushes the memory allocation into the SGA.
If either of these I/O slave options is configured, memory will be pulled from the shared pool area in the SGA, unless you have a large pool configured. If you do not have a large pool configured, and you expect to use I/O slaves, we highly recommend that you create a large pool with a size based on the total number of channels you expect to allocate for your backups, plus 1 MB for overhead.
Reference resources: Oracle Metalink, Oracle RMAN 10G backup&Recovery book by Matthew Hart and Freeman
