RMAN–Using RMAN

You can start using RMAN to back up and recover your databases with very little fanfare. When you install the Oracle server software, you’ll automatically install RMAN as well. You only absolutely need two things to start using RMAN: the database you want to back up (referred to as the target database) and the RMAN client, which is the interface you use to interact with the RMAN server processes that perform the actual backup and recovery tasks.

When you use RMAN to back up and recover your database files and objects, you use the RMAN client to interact with the database. The RMAN client interprets the RMAN commands you issue and starts up the necessary server sessions to process those commands. The term RMAN repository refers to the record of RMAN metadata about all backup and recovery actions on the target database. RMAN relies on this metadata when it performs backup and recovery operations.

By default, RMAN always stores a copy of the RMAN repository in the target database’s control file. Optionally, you can also use a recovery catalog for long-term storage of the RMAN repository. Whenever there is a change in the database structure, archived redo logs, or backups, RMAN updates the recovery catalog with the new information from the target database
control file. This way, you have an alternate source for the all-important RMAN repository data if you lose or can’t access the control file of the target database. In addition, the recovery catalog provides a long-term storage capacity for all RMAN backup and recovery information, whereas such older data is liable to be overwritten in the control file. The recovery catalog exists as a separate database schema, located ideally in a database separate from the target database(s). You can simplify your RMAN administration by using a single recovery catalog for all your Oracle databases.

You start up the RMAN client using the RMAN executable rman, which you’ll find in the $ORACLE_HOME/bin directory. In addition to the rman executable, RMAN also comes with two other internal components: one a set of PL/SQL procedures in the target database and the other a file named recover.bsq. RMAN turns the backup and recovery commands you issue into PL/SQL procedure calls using the recover.bsq file to construct the calls. After you start the
RMAN client, you must log in using either operating system credentials or database authentication. After logging in, you can issue backup and recovery instructions either by entering RMAN commands at the command line or by executing a script file that contains RMAN commands. You can also issue several types of SQL commands from the RMAN command line.
After you finish your backup and recovery session, you exit the RMAN client.

recover.bsq file is location in here - ?/rdbms/admin/recover.bsq

In addition to the target database and the RMAN client, the RMAN environment can have other optional elements. If you follow the Oracle’s backup and recovery recommendations you may also have a flash recovery area. In addition, you must have a media
management layer (MML) to interact with tape drives, since RMAN can’t work directly with the tape drives. RMAN can use either a third-party MML or Oracle’s own backup and recovery offering, called Oracle Secure Backup. The MML accesses and controls the tape libraries and manages the loading and unloading of tapes.

Finally, if you plan on working with several databases, it may be a smart idea to use an RMAN catalog database, which is a separate Oracle database dedicated to storing the recovery catalog. Although the recovery catalog isn’t mandatory, it provides two important advantages over using the database control file to store the RMAN metadata relating to backup and recovery
activity: you can store vastly greater amounts of data in the recovery catalog as compared to a control file, and you can store RMAN scripts inside the recovery catalog. By default, all RMAN-related records in the target database’s control file are overwritten after seven days, but you can control the length of retention by setting a higher value for the initialization parameter control_file_record_keep_time.

One may argue that since the control file can record all of RMAN’s metadata, there is no need to create and manage a separate recovery catalog database to store RMAN metadata. However, consider a situation where you lose all your control file copies at once. You can, of course, rebuild the control file quickly using the output of a recent alter database backup controlfile to trace command. However, when you re-create the control file using the output of that command, the one thing you do not get back is all the RMAN metadata that used to be stored in the control file! This and the fact that Oracle may always overwrite even useful
RMAN metadata in the control file means you should seriously consider using the recovery catalog. Oracle recommends using a recovery catalog in order to provide redundancy for your RMAN metadata. Chapter 6 discusses the recovery catalog in detail.