You are on page 1of 9

GETTING STARTED WITH RMAN

Darl Kuhn, Sun Microsystems Scott Schulze, Level 3 Communications Introduction
Oracle Recovery Manager (RMAN) is a tool that DBAs can use to backup, restore, and recover their databases. RMAN doesn't require an extra license or installation, it comes as a standard utility when you install the Oracle binaries. Although RMAN has been available since version 8.0, many organizations have been slow to adopt it. Change can be difficult, especially when tried-and-true database backup mechanisms have already been implemented. And no self-respecting database administrator wants to be blindsided when it comes to backup and recovery situations. But RMAN offers numerous advantages over the traditional techniques and thus warrants serious consideration when designing and implementing backup strategies. This paper will help you decide whether or not to use RMAN, and then discuss architectural and implementation decisions, before covering new Oracle9i RMAN features.

Why Use RMAN?
When your livelihood depends on your ability to back up and recover the database, why implement a technology like RMAN? The reason is that RMAN comes with several benefits: • Incremental backups that only copy data blocks that have changed since the last backup • • • • • • Tablespaces are not put in backup mode, thus no extra redo log is generated during online backups Detection of corrupt blocks during backup Parallelisation of I/O operations Automatic logging of all backup and recovery operations Built in reporting and listing commands Integration with Media Management Layer (MML)

RMAN’s incremental backup abilities could alone sway a decision for its use. The term “incremental” is used because RMAN has the ability to only backup those database blocks that have changed since a prior backup. Why is this important? Because the time and resources required to perform either a backup or a restore can be significantly diminished. Using this incremental feature ensures that the resources required to perform a backup are proportional to the transactional activity that has taken place within the database, and not to the size of the database; each block is read, but only modified blocks are written. For large databases, this provides a significant advantage over the traditional backup methods. When RMAN performs an on-line backup, the tablespaces are not put in backup mode. This means that there is no extra writing of entire blocks to the redo logs. For shops that experience high transaction volumes during backups, this could be a huge performance savings. Corruption needs to be detected at the earliest possible stage; before its presence finds its way into our “trusted” backup files. Prior to RMAN, common techniques would be to use full exports or perhaps DBVERIFY, each of which either has its own limitations or performance considerations. RMAN, however, has the presence of mind to check for corruption during the backup process; remember that each block is touched. If corruption is identified, it is logged to several dictionary tables which can be easily scanned and reported against. RMAN does not execute commands in a parallel fashion. RMAN will complete each command before it goes on to the next one in a serial fashion. Why is it then that parallelisation is touted as a benefit to using RMAN? It is because RMAN has the ability to allocate multiple processes at the same time to file copy operations. Thus, if you have multiple I/O devices, you can substantially reduce the time to backup or restore files. With traditional mechanisms, the onus is put on the DBA to record the specifics of each backup operation in case the backup is required for recovery purposes. RMAN, on the other hand, records the specifics of each backup operation within the

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

control files of the database that is being backed up. Having this information readily available not only facilitates database file restoration but also allows for the easy generation of risk assessment reports. Being able to determine the status of backup, restore, and recovery operations is of paramount importance to the DBA. RMAN comes with default, out of the box reporting facilities. For example, you can use RMAN commands to generate lists showing what backups have been made, when they were made, and the status of each. You can also write your own SQL to query the data dictionary views and report on all activity associated with backup and recovery. There are several companies that provide software to help with the management of reading and writing files to tape. This 3rd party software is often called the Media Management Layer (MML). The MML interfaces with your O/S to read and write files to tape, and it also keeps track of what files are on what tapes. RMAN can be configured to communicate directly with a MML. This relieves you from having to write your own code to do I/O with the tape devices and track what files went to which tape. In the event a file needs to be restored, this relieves the System Administrator, DBA, or tape operator of having to query the tape system for the required files.

RMAN Architecture
You should now have a good understanding of why you would want to use RMAN. If you are going to use RMAN, it is important that you understand how the pieces work together, and how it interacts with your Oracle database. This section details all of the critical components of RMAN: • RMAN executable • • • • • • Server processes Channels Target database Backups, backup sets, and backup pieces Recovery catalog database (optional) Media Management Layer (optional)

RMAN Executable
The RMAN executable, named rman, is the program that you use to manage all backup and recovery operations. You interact with the RMAN executable to specify backup and recovery operations that you want to perform. The rman executable then works with the target database, starts the required server processes, and performs the operations that you requested. Finally, the RMAN executable records those operations in the target database's control file, and in the recovery catalog database (if you are using one).

Server Processes
RMAN server processes are background processes started on the server that are used to communicate between RMAN and the databases being used, and also to communicate between RMAN and any I/O devices (disk or tape) being used. RMAN server processes do all the work for a backup or restore operation. A typical backup, restore, or copy operation will result in several server processes being started.

Channels
A channel is an RMAN server process that is started when there is a need to communicate to an I/O device, such as a disk or tape. A channel is what reads and writes RMAN backup files. Anytime you issue an RMAN allocate channel command, a server process is started on the target database host. It is through the allocation of channels that you manage I/O characteristics such as: • • Type of I/O device being read or written to Maximum size of files created on I/O devices

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

• • •

Number of processes simultaneously accessing an I/O device Maximum rate at which database files are read Maximum number of files open at a time

Target Database
The target database is the database that RMAN is going to operate on to perform backup, restore, and recovery operations. This is the database that owns the datafiles, control files, and archived redo files that are being backed up and recovered. RMAN does not backup the on-line redo logs of the target database.

Backups, Backup Sets, and Backup Pieces
What physically gets created when you issue an RMAN backup command? RMAN creates backup sets which are logical groupings of physical files. The physical files that RMAN creates on your backup media are called backup pieces. When working with RMAN, you need to understand that the following terms have very specific meanings: RMAN backup Not surprisingly, a backup is created anytime you run the RMAN backup command. A backup consists of one or more backup sets. Backup set There can be one or more backup sets created anytime you issue a backup command. An RMAN backup set is a logical grouping of the physical files associated with the backup. A backup set can have one or more backup pieces within it. Backup piece A physical file created by RMAN during a backup. Backup pieces are files written to your backup medium. Backup piece files contain physical blocks from the target database's datafiles, archived redo log files, and control files. RMAN is the only tool that can make use of backup piece files. When RMAN constructs a backup piece from datafiles, there are a several rules that it follows: • A datafile cannot span backup sets • • • A datafile can span backup pieces Datafiles and control files can be in the same backup set Archived redo log files are never in the same backup set as datafiles or control files

Recovery Catalog Database
The recovery catalog database is an optional information store for RMAN metadata concerning backup and recovery activities performed against the target database. The recovery catalog database consists of three components: • • • Usually a separate database from the target database A schema within the recovery catalog database Objects within the catalog schema that contain data pertaining to RMAN backup and recovery operations performed on the target

The catalog is typically a database that you build on a different machine than your target database. The reason for this is that you don't want a failure on the target machine to interfere with your ability to use the recovery catalog. If both recovery catalog and target are on the same box, a single hardware or media failure could put you in a scenario where you would not be able to recover your target database. Inside the catalog database is a special schema containing the tables used to store metadata information about RMAN backup and recovery activities. Why is the recovery catalog considered optional? When RMAN performs any backup operation, it writes information about that task to the target database control files. Therefore, RMAN does not need a catalog to function. If you choose to implement a recovery catalog database, then RMAN will additionally store the backup metadata in the catalog. A common

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

misconception is that the catalog stores the physical backup files for the target database. The catalog only contains information about the backups of the target database - not the physical backup files themselves. The advantage that a catalog brings to the table is that it can be used with many different target databases. This advantage allows you to manage all target backup and recovery activities from a centralized location. Additionally, a catalog allows for a longer history of backup operations.

Media Management Layer
The Media Management Layer (MML) is a 3rd party piece of software that manages the reading and writing of files to and from tape. A MML also keeps track of what O/S files have been written to what tapes. If you want to backup your database files to tape, RMAN requires the use of a MML. If you use RMAN to backup database files only to disk, then you do not need a MML. There are several reasons why you might want to backup files to tape, and thus require to use a MML: • Tape is more cost effective than disk, therefore your business requirement might be to backup all database files to tape (especially true for large databases) • Your wish to store your backup files somewhere other than on the same server as the target database, thus reducing your risk of losing both the target database and backup files at the same time

When backing up files to tape, an MML keeps track of what files were written to which tapes. In the event that restoration of a database file is required, RMAN will send to the MML a list of the database files that are required in order to restore the database. The MML will then determine which tapes store the required database files. The MML will then retrieve the requested files, send them back to RMAN, and RMAN will restore the database.

Comparison of a Hot Backup to RMAN On-line
To drive home some of the points, lets compare a hot backup with an RMAN on-line backup. Table 1 illustrates the traditional method to an Oracle8i and Oracle9i RMAN implementation. When reviewing this table, take a mental note of complexities that would be involved in writing an on-line (hot) backup script. Depending on a DBA’s skill at scripting, an on-line backup routine can be fairly complex since there is a change of context between those tasks that need to be accomplished from an Oracle perspective and those tasks that need to be accomplished from an O/S perspective.

Table 1. On-Line Backup Comparison Traditional On-Line (hot) Backup Identify tablespaces to backup Identify datafiles to backup Place tablespaces into backup mode Use an O/S copy mechanism to copy the datafiles Switch the on-line redo logs Backup the archived redo logs Backup the control file Oracle8i RMAN On-Line Backup RMAN provides this functionality RMAN provides this functionality Not necessary Accomplished with the backup command SQL is used from within RMAN to switch the on-line redo logs A separate RMAN backup command is executed SQL is used to backup the control file Oracle9i RMAN On-Line Backup RMAN provides this functionality RMAN provides this functionality Not necessary Accomplished with the backup command The on-line redo logs are switched as a result of the backup command The archived redo logs are backed up as a result of the backup command Issue this command just once and it will persist across all RMAN sessions
RMAN> configure controlfile autobackup on;

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

As you can see from this table, RMAN provides the functionality that the DBA would otherwise be responsible for when implementing an on-line backup routine. When boiling this table down to functional scripts for RMAN with Oracle8i and Oracle9i, they would respectively look something like:
RMAN> run { 2> allocate channel d1 type disk; 3> backup incremental level 2 4> format '/backupdir/rm_l_0_%d_%t_%U.bus' 5> database include current controlfile; 6> sql "alter system archive log current"; 7> release channel d1; 8> allocate channel d1 type disk; 9> backup format '/backupdir/rm_arch_%d_%t.bus' archivelog from time 'sysdate - 2'; 10> release channel d1; 11> sql "alter database backup controlfile to ''/backupdir/bckup_ctlfile.ctl'' reuse"; 12> }

Well, that is pretty simple but let’s compare it to an Oracle9i equivalent:

RMAN> backup database plus archivelog;

Wow! More on Oracle9i features in a bit.

Implementation Decisions
Before you use RMAN, there are several key implementation decisions that you should consider. The major implementation decisions revolve around some optional components of RMAN, specifically: • Implementing a recovery catalog or not • Implementing an MML or not

Catalog or Just Control File
One of the first decisions you'll have to make is whether or not to use a recovery catalog. The first point to make is that the recovery catalog is an optional component and that RMAN can be successfully implemented without a catalog. Here is a note from Oracle's 9i RMAN documentation, "RMAN works perfectly well without a recovery catalog. In fact, the recovery catalog receives all its information from the control file." Furthermore, you could argue that the recovery catalog adds a great deal of complexity to your backup and recovery architecture because it adds another network connection, server, and database that need to be accessed in the event of a backup or restore operation. So if you are trying to keep your backup and recovery strategy as simple as possible, why would you use a recovery catalog? Here are some reasons to consider: • • • • • Need to store information about backups for long periods of time Have a large numbers of datafiles (thousands) Desire to use scripts stored in the catalog Desire a centralized repository for all database backup operations Need a catalog to perform an RMAN restore of controlfiles (Oracle8i only)

If you decide not to implement a catalog, you may need to increase the parameter control_file_record_keep_time, because that controls the length of time that RMAN information is stored in the catalog before it is overwritten. Also if you do not use a catalog in an Oracle8i environment, ensure that you are backing up your controlfile outside of RMAN (i.e. SQL alter database backup controlfile command).

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

Tape or Disk
The MML is another optional RMAN component. Integrating with a MML allows you to write files directly to any media device supported by the MML. Usually you use a MML when you have a need to have RMAN write the backup files directly to tape. Here are the steps involved with a backup to tape: • • • Configure RMAN to backup to tape Implement MML Set channel type sbt_tape

The advantages of tape are that it allows for large amounts of database to be stored in the most economically feasible manner. Additionally if you are writing to tape, the MML keeps track of a long history of what database files have been backed up to which tapes, thus alleviates you of having to track that information. One of the disadvantages of using a MML is that it adds complexity; it adds another moving part in that you now have a tape device, 3rd party software, and a network connection added to your backup and recovery architecture. This can lead to more frustration during your RMAN implementation and more headaches when maintaining your implementation. If you don't implement a MML, then you are required to setup RMAN to write the backup files directly to disk. The steps involved with this are: • • • Set channel type disk Let O/S backup scrape files to tape Sometime after O/S backup has completed, delete RMAN backup files from disk

The advantages of a disk based implementation are that is straightforward to set up and maintain. You have fewer moving parts to maintain and manage. Additionally, disk access is usually much faster than tape access, so the time required to do a backup and restore are much shorter. The main disadvantage to writing backup files directly to disk is that disk space is usually finite, and therefore you cannot afford to store months and months of backup information on disk. In the scenario where you let the O/S backups copy the RMAN backups from disk to tape, and then you delete your RMAN backups from disk, if you need those files for recovery it is then up to you to inform the tape operator which files are required for restoration.

RMAN Oracle9i New Features
Oracle9i comes with new user-friendly features and performance enhancements to RMAN and also more flexibility in backup, restore, and recovery scenarios. Some of the major improvements are: • • • • • • Streamlined syntax for backup and restore Configurable persistent channel settings for your target environment Automatic backup of control file Improved options for backing up archived redo logs Performance optimization of backup and restore operations Block level recovery

Prior to Oracle9i, you were required to wrap backup, restore, and channel allocation operations within the RUN{} command syntax. This syntax can be a bit cumbersome, especially if you have to manually type in all of the required commands during a late night recovery scenario. With Oracle9i you no longer have that obligation. For example, the commands to restore and then recover your database now can be cut down to:
RMAN> restore database; RMAN> recover database;

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

This is made possible through a streamlined syntax and also the ability to configure channel settings that remain the same from one RMAN session to the next.

Configure Persistent Channel Configuration
One of the nice new features that makes things easier with your backup and recovery operations is the ability to configure persistent RMAN channel settings. Via the new RMAN Oracle9i CONFIGURE command, you can set defaults for channel file formats, degree of parallelism, device type, maximum read rate, maximum piece sizes, and so forth. The channel configuration settings are stored in the target database control file, thus you do not have to reissue channel configuration commands each time you issue a backup, restore, or copy command. The advantage to this is that you lessen the amount of code required to carry out an RMAN operation, which in turn lessens the likelihood of DBA introduced errors. Let’s compare a standards backup operation in Oracle8i with Oracle9i. Shown here is a standard Oracle8i backup script with the necessary run{} command and channel configuration settings:
RMAN> run { 2> allocate channel d1 type disk; 3> allocate channel d2 type disk; 4> setlimit channel d1 kbytes 1800000; 5> setlimit channel d2 kbytes 1800000; 6> backup format '/ora01/bck/rman%U.bus' database; 7> release channel d1; 8> release channel d2; 9> }

To achieve the same result in Oracle9i , first you specify your channel characteristics with the following two CONFIGURE commands:
RMAN> configure device type disk parallelism 2; RMAN> configure channel device type disk format = "/ora01/bck/rman%U.bus" 2> maxpiecesize 1800M;

And from that point forward, anytime you issue a backup command, RMAN automatically allocates two disk channels and creates the backup piece files with the preferred file format and specified size. After you configure your channel settings, the Oracle9i backup command becomes:
RMAN> backup database;

To display only the RMAN configuration settings that you have specifically set in your target environment, issue a query against the new v$rman_configuration view:
SQL> select * From v$rman_configuration;

If you want to see all of your channel configuration settings use the new SHOW ALL command. For example, this command displays your current target database channel settings:
RMAN> show all;

Autobackup of Control File
Another new ease-of-use-feature provides you with the capability to have your control file automatically backed up. Once the control file autobackup feature is enabled, anytime you kick off a BACKUP or COPY command, your control file is automatically backed up. You can enable this option by using the CONFIGURE command as follows:
RMAN> configure controlfile autobackup on;

There are two big advantages in using this feature to backup your control file:

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

• •

Ensures your control file is backed up frequently Relieves you of being reliant on a recovery catalog in certain restore control file situations

When AUTOBACKUP is enabled, you are certain to have a backup of your control file each time you initiate a backup operation. This alleviates you of having to manually type in or script these commands each time you want to backup the control file. With Oracle8i, Oracle recommended implementing RMAN with a recovery catalog. One of the important reasons for using a recovery catalog was that it gave you the capability to recover your control file in the situation where you had lost all control files. With Oracle8i, in the event you lost all of your control files, you were required to connect to a recovery catalog when using RMAN to restore them. With Oracle9i, if you have enabled the autobackup of your control files, you are no longer required to connect to a recovery catalog to restore your control files. This provides you with the flexibility of being able to recover control files in the event your recovery catalog is unavailable.

Automated Archive Redo Log File Backup Tasks
Archived redo log files are an important part of a backup and recovery strategy. Oracle9i RMAN gives you some new alternatives for backing up these essential files. For example, before Oracle9i, you had to manually script your backups to switch the on-line redo logs and backup any archived redo logs generated during the backup. Here’s a typical Oracle8i script that does that:
run { allocate channel d1 type disk; backup database format ‘/ora01/bck/rman_%U.bus’; sql “alter system archive log current”; backup archivelog all format ‘/ora01/bck/archlog_%U.bus’; release channel d1; }

Archived redo logs are backed up in this fashion to make sure that the database datafiles can be recovered to a consistent state. Now with Oracle9i, this can all be automated via the BACKUP PLUS ARCHIVELOG command. For example, if you want to backup all database files and additionally the archived redo log files, you would use the following command:
RMAN> backup database plus archivelog;

When you use this command RMAN performs the following commands for you in this order: 1. Runs ALTER SYSTEM ARCHIVE LOG CURRENT command 2. Issues the BACKUP ARCHIVELOG ALL command 3. Backs up all files as specified by the BACKUP command 4. 5. Runs ALTER SYSTEM ARCHIVE LOG CURRENT command Backs up all archived redo logs that have been generated during the backup

Backup and Restore Performance Improvements
Oracle9i RMAN backup and restore operations have slightly changed to improve performance. Backups can now be configured to skip files that have not changed since the last backup. This feature is enabled with the CONFIGURE OPTIMIZATION command as shown:
RMAN> configure backup optimization on;

This new command tells RMAN to check previously backed up files and examine the timestamp and SCN, and if no changes are detected, then the file is not backed up again. This could be especially handy when backing up archived redo log files, because these files are static and do not change. The RESTORE command has also been enhanced to improve performance. Previous to Oralce9i, when you issued a restore command, RMAN copied back all of the specified datafiles whether they needed media recovery or not. With Oracle9i,

www.rmoug.org

RMOUG Training Days 2002

Getting Started with RMAN

Kuhn and Schulze

before RMAN restores a file it checks to see if the file is in the proper location and also examines the file header. If RMAN finds the correct information in the file header, it will not restore the datafile. The benefit of this is that if you issued a RESTORE DATABASE command and only one file was missing or corrupt, that file would be the only file restored, thus saving you time during a full database recovery. You can override this default behavior via the new FORCE option of the RESTORE command.

Recover at the Block Level
With Oracle8i, the lowest level of recoverability was at the datafile level. That changed in Oracle9i with the new RMAN BLOCKRECOVER command. This command gives you the capability to recover isolated corrupt blocks, even while the datafile is online. RMAN as a normal part of doing a backup or copy operation will check each block for corruption and log the results. Corrupt media can then be queried from the v$backup_corruption and v$copy_corruption views. To report on corrupt blocks that have been detected during an RMAN copy or backup operation:
SQL> select * from v$copy_corruption; SQL> select * from v$backup_corruption;

And then to recover all blocks reported as corrupt from the above queries, use the CORRUPTION LIST option of the BLOCKRECOVER command:
RMAN> blockrecover corruption list;

Alternatively, you can recover specific blocks. In this example, block number 20 of datafile number 3 was detected as corrupt and is recovered as follows:
RMAN> blockrecover datafile 3 block 20;

The advantage to block level recovery is that if you discover you have corrupt blocks in a large datafile, instead of having to restore and recover the entire datafile, you can now selectively recover only the bad blocks. This could significantly reduce the amo unt of time it takes you to restore and recover. Block level recovery is not intended to replace datafile recovery, it should be used in cases where you have small numbers of isolated corrupt blocks.

About the Authors
Darl Kuhn (darl.kuhn@sun.com), an Oracle DBA and software developer with 14 years experience, is a senior DBA with Sun Microsystems. Before joining Sun, his work as a consultant ranged from database administration to custom application development. Darl is the coauthor of the O'Reilly book RMAN Pocket Reference, and enjoys learning and exploring new Oracle technologies. Scott Schulze (scott.schulze@level3.com), an Oracle DBA and software developer with 12 years experience, is a senior DBA at Level(3) Communications. Scott has worked for several companies in the telecom and data storage industries. Scott is the coauthor of the O’Reilly book RMAN Pocket Reference. He has also taught Oracle relational modeling and PL/SQL courses for the graduate department of Computer Information Systems at Regis University.

www.rmoug.org

RMOUG Training Days 2002