By: Juan Carlos Olamendy Turruellas
This is the third article in a series where we’re being learning about the principles, concepts and real world scripts for doing backups to Oracle database.
In the first article, I’ve talked about the most important terms related to backups in Oracle databases. In this second article, I’ve talked about doing low-level manual backups in order to illustrate the principles and concepts of the first article. In this article, I want to talk about the architecture, key concepts and terms related to Recovery Manager (also know as RMAN). And in the last fourth article, we’ll apply the concepts learned in this article with practical examples in real-world scenarios.
From the previous article, we see how to do low-level manual backups by using the OS commands to copy the relevant files to a different location and/or to a tape device.
In this article, I’ll introduce a tool named RMAN that simplifies the work of DBAs related to backup and restore of databases in Oracle.
Using RMAN, we can back up the database from within the Oracle instance with the help of the server itself. RMAN can make backups of database files and database file image copies, control files and control file image copies, archived redo logs, the SPFILE, and RMAN backup pieces. Oracle recommends strongly using the RMAN tool for backing up the databases.
The key features of RMAN not available with low-level backup methods that improve significantly the backup activities are:
There are several backup types as shown in the list below:
It's remarkable to say that RMAN doesn't come with capacity to directly read and write to tape device. If we want to make backups to tape devices, we'll need additional software called Media Management Library from the tape software vendor.
Now I’ll talk about the anatomy of the RMAN tool. RMAN operates via server sessions connecting to the target databases. A target database is the one that we want to backup or recover. The collection of information about the target database, such as its schema information, backup copy information, configuration settings, and backup and recovery scripts, is called the RMAN recovery repository. RMAN uses the metadata related to the target databases to perform its backup and recovery activities. RMAN periodically retrieves metadata from the target database control file and saves it in the recovery catalog.
The key components of the RMAN architecture are:
By default, the control file is the primary storage for RMAN’s repository. We have a choice of two locations for storing the RMAN catalog/repository: in the control file, or the optional recovery catalog (it’s optional but it’s very recommended). The recovery catalog schema is a series of tables and views owned by the RMAN user populated with backup and recovery information for one or more databases. At the end of the day, all RMAN information is first written in the control file, and then optionally to the recovery catalog if one exists.
Oracle recommends that we use a dedicated database for running the recovery catalog, although it isn’t necessary at all.
There are pro and cons for going through the recovery catalog option:
We can visualize the RMAN architecture using the diagram shown below in the figure 01.
In this third part, I've introduced the architecture and key concepts related to RMAN tool. Next article, it’s the demo part with real-world examples. You can see this article as the starting point to understand the RMAN tool and apply it to your own scenarios.