Oracle RMAN connection decoded

Oracle RMAN is a important tool used in Backup and recovery. Whenever you use RMAN tool in $ORACLE_HOME/bin and connect to database, it makes multiple connection to the database.Here are RMAN connection decoded

Whenever we make RMAN connection to database for backup with or with out catalog,many processes are spawned and worked upon. RMAN always spawns TWO processes (sessions) when connected to a target database:
• 1st default channel
• polling channel
ALL other processes (sessions) are spawned sequentially according to the backup configuration used. RMAN commands are executed sequentially according to their order of appearance in the backup script.

(1) RMAN client
The backup process is driven by the RMAN client. It is responsible for parsing rman commands, generating pl/sql programs (one per channel) to carry out the RMAN backup, balancing the workload across the allocated channels and executing the backup and catalog/controlfile resyncs/queries via a series of Remote Procedure Calls (RPC) to the target and catalog databases.
If an RMAN debug trace is requested, this is the process that is traced.

(2) 1st Default Channel
All RPC calls issued by the RMAN client to the target (other than the backup itself) is executed by this channel: compatibility checks during connection, queries against the controlfile during backup and catalog resync operations, execution of all sql statements issued via RMAN (mount, open, setting events etc). If a bottleneck in the Oracle layer is suspected, this is the process to be traced.

(3) Polling Channel
Used for polling each allocated channel to see current state of last RPC made and determine if it is ready for the next RPC from the client. From a performance perspective you can ignore this process.

(4) Allocated Channel (tape or disk)

The allocated channel has only one purpose: to read data blocks from disk into an input buffer, to transfer that data to an output buffer and then to make a request to the media manager (or OS) that the block be written to the appropriate device. During transfer to the output buffer, corruption checks are made hence only blocks included in the backuppiece are checked for corruption. If a bottleneck in the the media manager is is suspected, this is the process to be traced.

(5) Disk IO Slaves
Disk IO slaves should always be used to simulate asynchronous IO when native asynchronous IO is disabled. There are always 4 slaves spawned initially per channel but slaves will die if idle > 60 secs.

(6) Tape IO Slave
If BACKUP_TAPE_IO_SLAVES=TRUE a single tape slave per channel is used. This speeds up the backup if the bottleneck is in writing to tape; it frees the channel process to continue processing rman input buffers whilst the tape slave waits for IO completion.

(7) Media Manager Client

This is the 3rd party media manager library used for writing to tape – each target host needs to have this installed. All calls to the media manager layer take the form of a C program call to an sbt routine – there are 2 outcomes to each call:

success: 0
failure: non zero
If we do not exit from the call we will wait forever: this is a hang in the media manager layer.
(8) Catalog Connection
If a catalog repository is used:
• a session is spawned (via SQLNet) in the catalog instance
• the catalog is implicitly resynced against the controlfile before and after running rman commands
• once the resync is done, all queries of RMAN metadata will run against the catalog only
• all updates to RMAN medata are made to the controlfile FIRST and then propogated into the recovery catalog via an implicit resync
If a bottleneck in the recovery catalog is suspected, this is the process that is traced.

Related Posts

Leave a Comment Cancel Reply