Just began reading this book, in aid of my (short-term) memory, here are (the first of) a few excerpts from that book, after the jump:
RMAN-08512: waiting for snapshot controlfile enqueue
This error happens when the snapshot controlfile header is locked
by a process other than the one requesting the enqueue.
Prob. multiple backup jobs simultaneously from different RMAN sessions:
SELECT s.sid , username , program , module , action , logon_time "Logon" , l.* FROM V$SESSION s , V$ENQUEUE_LOCK l WHERE l.sid = s.sid AND l.type = 'CF' AND l.id1 = 0 AND l.id2 = 2 /
SYS.DBMS_RCVMAN
This package is used to acces the tables in the controlfile and pass this onformation to RMAN
so it can build backup and restore operations. This package is responsible for setting TIME operators,
verifying checkpoint information in the datafile headers prior to running operations, checks file
locations and sizes, any information concerning node affinity (RAC) and disk affinity.
SYS.DBMS_BACKUP_RESTORE
SYS.DBMS_RCVMAN gathers all information and passes it to the RMAN server process, which then creates
PL/SQL blocks based on the ‘recover.bsq’ file. These PL/SQL blocks consist of calls to the package
DBMS_BACKUP_RESTORE. DBMS_BACKUP_RESTORE is the actual package that creates system calls to backup
datafiles, controlfiles and archived redologs. It is the work of DBMS_BACKUP_RESTORE that you can
follow in V$SESSION_LONGOPS. It also backs up the (snapshot) controlfile (read consistency) and writes
information in the actual controlfile about when the backup was taken, how long it took and the size
and name of the backup.
In version 10g, RMAN has whitespace compression (like a ZIP utility), the provides actual compression
of the backed up blocks themselves. In addition, the block-change tracking file allows RMAN to skip
some blocks during backup without reading them into a memory buffer (this is where the time is saved).
From 10gR2 patchset 1, RMAN can do empty block compression. From this point on, RMAN can skip nulls
and remove empty blocks from the backupsets.
Memory buffers on a per-file basis, during backup:
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 /
Input memory buffers are sized according to the number of datafiles and the number of channels
(with respect to the load balancing that will occur during backup), here are the rules:
#files =< 4 = 4 buffers p/f @ 1 MB p/b -> total = 16 MB #files > 4 =< 8 = 4 buffers p/f @ 1/2 MB p/b -> total = 16 MB or less #files > 8 = 4 buffers p/f @ 1/8 MB p/b -> Each file will account for 512KB of (input)buffer memory
Outputbuffers are different per output source, when backing up to disk RMAN will allocate 4 output
buffers per channel. Each of these is 1 MB in size, so the entire emory footprint is per channel will
be 4 MB. In the case of backing up to tape, the output buffers are 256 KB in size. This to account for
the slower I/O rate expected from tape devices. The total footprint will be 1 MB per channel.
During restore, all this will be reversed and this sizing will be true for the input resp. output memory buffers.