By: Juan Carlos Olamendy Turruellas

Introduction

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.

RMAN key features

The key features of RMAN not available with low-level backup methods that improve significantly the backup activities are:

  • Skip unused blocks: Blocks that have never been written to in a table are not backed up by RMAN
  • Backup compression: RMAN provides a binary compression mode that optimizes compression for the typical kind of data found in enterprise applications. The drawback is that it slightly increases the CPU usage and total time required for backup and recovery
  • Open database backups: Tablespace backups with RMAN can be done without using BEGIN/END BACKUP clause. The database must be in ARCHIVELOG mode
  • True incremental backups: RMAN does not write unchanged blocks since the last backup
  • Block-level recovery: RMAN supports block-level recovery to enable restoring or repairing a small number of blocks identified as being corrupt during the backup operation. This keeps the rest of the tablespace online
  • Multiple I/O Channels: RMAN supports multi-threaded operations for backup and recovery
  • Platform independence: Backups written with RMAN commands are syntactically identical regardless of the operating system or hardware platform
  • Tape manager support: All major enterprise backup systems from 3rd parties support RMAN.
  • Cataloging: A record of all RMAN backups are recorded in the target database control files or optionally to a recovery catalog stored in a different database
  • Scripting capabilities: RMAN scripts can be saved in a recovery catalog for retrieval during backup sessions.

Backup types

There are several backup types as shown in the list below:

  • Consistent and inconsistent backups a physical backup is consistent when all database files have the same SCN. It occurs when all changes in redo log files have committed to database files. An inconsistent backup results when the database is open and the users are using the database
  • Full backup. It includes all blocks of every database file. It’s essentially a bit-for-bit copy
  • Incremental backup. RMANsupports incremental backups as level 0 or level 1.
    • Level 0. A full backup of all blocks
    • Level 1. A backup of only changed blocks
    • Image copies. These are full backups done with OS commands such as the LINUX/UNIX cp command, or the RMAN backup as copy commands
    • Backupsets and backup pieces. In contrast to image copies, backupsets can be created and restored only with RMAN
      • A backupset is an RMAN backup of part or all of a database consisting of one or more backup pieces
      • Each backup piece belongs to only one backupset and can contain backups of one or more datafiles in the database
      • Compressed Backups. It compressed backups are only usable by RMAN and require no special processing in a recovery operation. Compression option is automatic with RMAN

RMAN and tape devices

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.

RMAN architecture

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:

  • RMAN client: This is the binary named rman installed in your system and located at $ORACLE_HOME/bin. This program performs all backup and recovery operations and records the results in the control file and the optional recovery catalog. We issue RMAN commands and SQL statement through the RMAN client and the command-line interface. It starts a server sessions on the target database and manages the backup and recovery operations. It uses Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net protocol.
  • Target database: This is the Oracle database to which RMAN connects and it needs to back up and recover. RMAN server sessions running in the target database perform the backup and recovery operations.
  • Server-side processes. These are the background processes that facilitate communication between the RMAN executable and the target database. The server processes perform the real work of reading and writing to disk devices and tape drives during backup and recovery.
  • Flash recovery area. This is a new component added since Oracle 10g. This is an area on disk for the storage of backup and recovery related files. Using this area simplifies the ongoing administration of the database by automatically naming recovery-related files, retaining them as long as they are needed for restore and recovery activities, and deleting them when they are no longer needed to restore your database and space is needed for some other backup and recovery-related purpose.
  • Media Management Library: To store the backup of our database on tape devices, we need to install the media manager software of the third-part vendor and use Media Management Layer (MML) APIs that are available in RMAN. While backing up the database, RMAN connects to the media manager using specific allocated channels via the target database instance. To install the third part media manager, we need to refer to the vendor's software documentation for instructions.
  • Recovery catalog. This is the RMAN’srepository and contains information about:
    • Database file backup sets and copies
    • Archived redo log copies and backup sets
    • Tablespaces and database file information
    • Stored scripts and RMAN configuration settings

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:

  • Cons: Recovery catalog may be too complex to maintain because we’re dealing with another database to manage
  • Pros: We can also use RMAN-stored scripts if only if we use the recovery catalog. If we use the control file, we may overwrite some historical data while the recovery catalog will safeguard all such data because the control file allocates a finite space for backup-related activities, while the recovery catalog has more room for storing backup history

We can visualize the RMAN architecture using the diagram shown below in the figure 01.

Figure 01

Conclusion

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.