The architecture of RMAN combines the interactive user utilities and databases with RMAN’s utility executable programs and background processes. These built-in tools allow the Database Administrators to easily backup and recover the data in an Oracle database. Some of the vital architectural mechanisms that ensures that transaction integrity is preserved and sufficient information is maintained to recover the database to any appropriate point include channels, target database(s), recovery catalog database, executable files, server processes, backup systems, and so forth. Some of the reasons for implementing RMAN are discussed below (Kuhn & Schulze).

One of the architectural decisions is making a choice on the number of channels to use for backing up and recovering databases because some storage servers cannot handle the load of parallel backup tape streams. You can write backup set to disk or tape, however, you need a MML to write to tape. The Storage Admin can set the number of channels that a storage server allows. In respect to this and to ensure better performance, RMAN channel represent one stream of data to a device type, and corresponds to one server session. That is, each channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance. Most backup and recovery commands in RMAN are executed by server sessions. Moreover, the new RMAN features include automated channel failover for backup and restore (Oracle User's Guide).

Another factor is creating recovery catalog database, which should be on a different host, on different disks, and in a different database from the target database you will be backing up. If you do not, the benefits of using a recovery catalog are lost if you loose the database and need to restore. The modern RMAN recovery catalogs act like virtual private, which is used to improve security, and the import catalog command is used to merge one recovery catalog into another. A catalog enables you to recover your control files in the event that they are all corrupted or lost. This was especially true in version 8, but is not an issue in version 9 and above. A catalog performs full resync, to synchronize all information for creating a snapshot of the controlfile, to avoid concurrency problems and to get consistent results (Gorman).

Furthermore, RMAN has a powerful and flexible incremental backup mechanism that only backs up those database blocks that have changed since a prior backup. The ability to perform incremental and cumulative backups of datafiles greatly improves the performance of backups. Without this ability, only full image copies of the datafilesare possible.  The greatest performance improvements will be realized by large databases in which only a small subset of a large tablespace changes. Hence you only backup the blocks that have changed since the last backup. Incremental backups can reduce the absolute volume of data sent to backup media noticeably. If available, incremental backup automatically uses the block change-tacking file to save time and cpu cycles every day instead of once a week (Kuhn et al, 2007).

In addition, instead of maintaining multiple levels of backups across multiple days, you can have your incremental backups dynamically merge with prior backups. The merge occurs as part of backup command within RMAN, to create a copy of the prior backup and merge that with the new incremental changes. This comes in handy in warehouse environments, where many operations are done in nologging mode and data changes do not go to the archived log files; hence, no media recovery is possible.

The capabilities of RMAN are better suited for backing up the database archive logs (i.e. making it automated). The retention policy of RMAN is very important in backing up archived redo log files. That is, it specifies the number of file copies to backup and delete once they are backed-up. It can be defined to apply to all as mandatory and optional remote archive log destination (Freeman).  As noted above, RMANs has a considerable advantage over user-managed database backups. It should also be noted that RMAN has its shortcomings but its evolving and gaining considerable acceptance.



References:

Kuhn, D., Alapati, S., & Nanda, A. (2007). RMAN Recipes for Oracle Database 11g A Problem Solution Approach. Apress.

Rajan, C. (2007). Database Administrator II: Backup/Recovery & Network Administration. Thompson.

Powell, G. & McCollough-Dieter, C. (2007). Database Administrator: Implementation & Administration. Thompson.

Kuhn, Darl, & Schulze, Scott: Oracle RMAN Pocket Reference
http://www.oreilly.com/catalog/rman/cover.html

Freeman, Robert G. (2008). Oracle Database 11g, New Features. McGraw Hill-Orsbone

Gorman, Tim. IS RMAN REALLY WORTH THE TROUBLE?
http://www.evdbt.com/TD_Rman.pdf

Oracle Database Backup and Recovery Advanced User's Guide 10g
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10734/rcmconc1.htm


Cooksey, Donna and Nanda, Arup ORACLE RECOVERY MANAGER 10g: Exploring RMAN’s Unique Data Recovery Capabilities
http://www.oracle.com/technology/deploy/availability/pdf/1181_Cooksey_WP.pdf