The basics of RMAN(Oracle’s Recovery Manager)

Oracle Recovery Manager (RMAN) takes backup and recovery to a new level of security and ease of use. Since the appearance of RMAN in Oracle version 8, many changes have occurred. key improvements and enhancements that can make RMAN a "one-stop shop" solution for almost any database, including Oracle multitenancy providers Architecture features are available for the first time in Oracle Database 12c. In addition to the RMAN CLI upgrade in Oracle 12c, all RMAN features have been added. Enterprise Manager Cloud Control 12c (EM Cloud Control) web interface, allows DBA to monitor and perform backup operations when only a web browser connection is available. we'll use several RMAN performance examples, using the command line interface. An example will cover the scope of RMAN Configuring the environment for backup and recovery and backup itself. We will enter some details about how RMAN manages the metadata associated with the database as well as Background. Finally, we will cover several different topics, such as using RMAN catalog backups performed outside the RMAN environment.

RMAN Features and Components

RMAN is not the only client side that can be used with a web interface. It includes many other things, including the database to be supported (the target database), an optional recovery catalog, an optional recovery zone, and media management software for the backup tape support system. We will briefly examine each of them in this section Many features of RMAN have no equivalent to the backup methods presented in Chapter 13. We will compare the pros and cons of using RMAN with a more traditional systems background.

RMAN components 

• Target Database - the Oracle database in which the backup or recovery operations are being performed.
• RMAN Client – executable that interprets commands, directs server sessions to execute those commands, and records its activity in the target database control file (or catalog). 
• Fast Recovery Area (Optional) - a disk location that you can use to store recovery-related files such as control files and online redo log copies, archived redo log files, flashback logs, and RMAN backups. 
• Media Manager (Optional) - an application required for RMAN to interface with sequential media devices such as tape libraries. A media manager controls these devices during backup and recovery, managing the loading, labeling, and unloading of media.
• Recovery Catalog (Optional) - A separate database schema used to record activity against one or more target databases. A recovery catalog preserves RMAN repository metadata if the control file is lost, making it much easier to restore and recover following the loss of the control file.

RMAN vs. Traditional Backup Methods

There are very few reasons not to use RMAN as your primary backup management tool. Here are some of the major features of RMAN that are not available with traditional backup methods or have significant restrictions using traditional backup methods:

■ Skip unused blocks: Blocks that have never been written to, such as blocks above the 

high-water mark (HWM) in a table, are not backed up by RMAN when the backup is an 

RMAN backupset. Traditional backup methods have no way of knowing which blocks have 

been used.

■ Backup Compression: In addition to skipping blocks that have never been used, RMAN can also use one of several Oracle-specific binary compression modes to save space on the backup device. Although operating system–specific compression techniques are available with traditional backup methods, the compression algorithm used by RMAN is customized to maximize the compression for the typical kinds of data found in Oracle data blocks. Although there is a slight increase in CPU time during an RMAN compressed backup or recovery operation, the amount of media used for backup may be significantly reduced, as well as network bandwidth if the backup is performed over the network. Multiple CPUs can be configured for an RMAN backup to help alleviate the compression overhead.

■ Open Database Backups: Tablespace backups can be performed in RMAN without using the BEGIN/END BACKUP clause with ALTER TABLESPACE. Whether using RMAN or a traditional backup method, however, the database must be in ARCHIVELOG mode.

■ True Incremental Backups: For any RMAN incremental backup, unchanged blocks since the last backup will not be written to the backup file. This saves a significant amount of disk space, I/O time, and CPU time. For restore and recovery operations, RMAN supports incrementally updated backups. Data blocks from an incremental backup are applied to a previous backup to potentially reduce the amount of time and number of files that need to be accessed to perform a recovery operation. We will cover an example of an incrementally updated backup later in this chapter.

■ Block-level Recovery: To potentially avoid downtime during a recovery operation, RMAN supports block-level recovery for recovery operations that only need to restore or repair a small number of blocks identified as being corrupt during the backup operation. The rest of the tablespace and the objects within the tablespace can remain online while RMAN repairs the damaged blocks. The rows of a table not being repaired by RMAN are even available to applications and users.

■ Table-level Recovery: When logical backups of a table aren’t available or when FLASHBACK TABLE cannot bring back a table to a previous state, you can use RMAN to restore a table or tables from an RMAN backup as of any SCN since the last full RMAN backup with the database in ARCHIVELOG mode. This makes table-level recovery much easier than having to restore and recover an entire tablespace, much less the entire database, for just one table.

■ Multiple I/O Channels: During a backup or recovery operation, RMAN can utilize many I/O channels, via separate operating system processes, to perform concurrent I/O. Traditional backup methods, such as a Unix cp command, are typically single-threaded operations.

■ Platform Independence: Backups written with RMAN commands will be syntactically identical regardless of the hardware or software platform used, with the only difference being the media management channel configuration. On the other hand, a Unix script with lots of cp commands will not run very well if the backup script is migrated to a Windows platform!

■ Tape Manager Support: All major enterprise backup systems are supported within RMAN by a third-party media management driver provided by a tape backup vendor.

■ Cataloging: A record of all RMAN backups is recorded in the target database control file, and optionally in a recovery catalog stored in a different database. This makes restore and recovery operations relatively simple compared to manually tracking operating system–level backups using “copy” commands.

■ Scripting Capabilities: RMAN scripts can be saved in a recovery catalog for retrieval during a backup session. The tight integration of the scripting language, the ease of maintaining scripts in RMAN, and the Oracle scheduling facility make it a better choice than storing traditional operating system scripts in an operating system directory with the operating system’s native scheduling mechanisms.

■ Encrypted Backups: RMAN uses backup encryption integrated into Oracle Database 12c (including advanced compression) to store encrypted backups. Storing encrypted backups on tape requires the Advanced Security Option. In a few limited cases, a traditional backup method may have an advantage over RMAN; but now that RMAN supports the backup of password files and other non-database files such as tnsnames.ora, listener.ora, and sqlnet.ora (using Oracle Secure Backup), the case for RMAN as your single backup and recovery solution is compelling.

Backup Types 

RMAN supports several different backup methods, depending on your availability needs, the desired size of your recovery window, and the amount of downtime you can endure while the database or a part of the database is involved in a recovery operation.

Consistent and Inconsistent Backups

A physical backup can be classified by being a consistent or an inconsistent backup. In a consistent backup, all data files have the same SCN; in other words, all changes in the redo logs have been applied to the data files. Because an open database with no uncommitted transactions may have some dirty blocks in the buffer cache, an open database backup can rarely be considered consistent. As a result, consistent backups are taken when the database is shut down normally or in a MOUNT state.In contrast, an inconsistent backup is performed while the database is open and users are accessing the database. Because the SCNs of the data files typically do not match when an inconsistent backup is taking place, a recovery operation performed using an inconsistent backup must rely on both archived and online redo log files to bring the database into a consistent state before it is opened. As a result, a database must be in ARCHIVELOG mode to use an inconsistent backup method.

Full and Incremental Backups

Full backups include all blocks of every data file within a tablespace or a database; it is essentially a bit-for-bit copy of one or more data files in the database. Either RMAN or an operating system command can be used to perform a full backup, although backups performed outside of RMAN must be cataloged with RMAN before they can be used in an RMAN recovery operation.In Oracle 11g and later, incremental backups can be level 0 or level 1. A level 0 backup is a full backup of all blocks in the database that can be used in conjunction with differential, incremental, or cumulative incremental level 1 backup in a database recovery operation. A distinct advantage to using an incremental backup in a recovery strategy is that archived and online redo log files may not be necessary to restore a database or tablespace to a consistent state; the incremental backups may have some or all of the blocks needed. An example of using level 0 and level 1 incremental backups is presented later in this chapter. Incremental backups can only be performed within RMAN.

Image Copies

Image copies are full backups created by operating system commands or RMAN BACKUP AS COPY commands. Although a full backup created with a Unix cp command can be later registered in the RMAN catalog as a database backup, doing the same image copy backup in RMAN has the advantage of checking for corrupt blocks as they are being read by RMAN and recording the information about the bad blocks in the data dictionary. Image copies are the default backup file format in RMAN. This is a great feature of Oracle 12c’s RMAN for the following reason: If you add another datafile to a tablespace, you need to also remember to add the new datafile to your Unix script cp command. By creating image copies using RMAN, all datafiles will automatically be included in the backup. Forgetting to add the new datafile to a Unix script will make a recovery situation extremely inconvenient at best and a disaster at worst.

Backupsets and Backup Pieces

In contrast to image copies, which can be created in almost any backup environment, backup sets can be created and restored only with RMAN. A backup set 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 many datafiles in the database. All backup sets and pieces are recorded in the RMAN repository, the same as any other RMAN-initiated backup.

Compressed Backups

For any Oracle 12c RMAN backup creating a backupset, compression is available to reduce the amount of disk space or tape needed to store the backup. Compressed backups are only usable by RMAN, and they need no special processing when used in a recovery operation; RMAN automatically decompresses the backup. Creating compressed backups is as easy as specifying AS COMPRESSED BACKUPSET and COMPRESSION ALGORITHM in the RMAN BACKUP command or as part of the default settings.