RMAN uses dedicated server sessions, so called channels to create backups.
As of Oracle database 9i it is possible to use the CONFIGURE command to store RMAN configuration information in the controlfile of the target database. You can use the SHOW command to look at all the RMAN configuration information in the controlfile:
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_orcl.f’; # default
It is important to know that RMAN uses process memory (PGA memory) to create INPUT-BUFFERS and OUTPUT-BUFFERS. RMAN reads the datablocks through the INPUT-BUFFERS and writes them though the OUTPUT-BUFFERS to disk or tape.
Let’s have a closer look at these buffers and how they use memory.
The INPUT-BUFFERS can reach a maximum total size of 16Mb/channel.
The number of channels is controlled by using the PARALLELISM parameter in the CONFIGURE command.
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
If you do not use asynchronous I/O which not every operating system is capable of,
RMAN can use I/O slaves to read data into the INPUT-BUFFERS.
You can inplement this by setting the initialization parameter DBWR_IO_SLAVES to anything larger than zero.
If this is the case RMAN will always use 4 I/O slaves to load the blocks from disk into memory. These I/O slaves must be able to communicate with each other and therefore must use shared memory.
If no LARGE POOL is defined RMAN uses the SHARED POOL.
In this case you should definitely define a LARGE POOL !!!
Additionally you can use the initialization parameter BACKUP_TAPE_IO_SLAVES for Recovery Manager to back up, copy, or restore data to tape.
If this parameter is set to TRUE tape buffers are allocated from shared memory (SGA) if the parameter is set to FALSE these buffers are allocated in the PGA of the channel process.
The size of the OUTPUT-BUFFERs depends on the kind of backup destination you use:
- for backups to tape RMAN allocates 4 OUTPUT-BUFFERs of 256 bytes each per channel
which makes up 1Mb per tape-channel.
- for backups to disk RMAN allocates 4 OUTPUT-BUFFERs of 1 Mb each per channel,
so it uses 4Mb per disk-channel.
You can use dynamic performance views to monitor these buffers:
Now let us take a look at the shared memory utilization of the I/O slaves:
as I have already mentioned these slave processes utilize SHARED MEMORY in the LARGE POOL.
If LARGE_POOL_SIZE is not set at all and you do not use Automatic Shared Memory Management (ASMM) in Oracle database 10g then memory from the SHARED POOL is utilized.
This is something we definitely will not want!!
So again YOU SHOULD CREATE A LARGE POOL FOR IO SLAVES !!!!
If LARGE_POOL_SIZE is set to a too small value (not enough forr all the buffers)
then no SHARED POOL MEMORY is utilized! If RMAN cannot get enough shared memory in this case, it allocates memory from the local PGA of the channel server process and writes a message to the alert.log.
The minimum size of the LARGE POOL for RMAN can be calculated with this formula:
The size of the tape_buffer is 0 for disk channels and defaults to 256K for tape channels (this can be adjusted with the BLKSIZE parameter in the channel configuration).
the LARGE POOL (resp. the SHARED POOL if there is no LARGE POOL)
is only utilized when
- for disk buffers DBWO_IO_SLAVES > 0
- for tape buffers BACKUP_TAPE_IO_SLAVES = TRUE
It is automatically adjusted as needed depending on the overall workload of the system
if you use ASSM (SGA_TARGET > 0) in 10g.