RMAN Basics


Oracle's Recovery Manager, also known as RMAN, should be your tool of choice when it comes to backing up Oracle databases. RMAN was first introduced in Oracle 8.0 and has come a long way since then. This chapter shows how RMAN has been improved specifically in Oracle Database 10g. It also offers some practical tips that you can use in configuring and using RMAN for both backup as well as recovery. Before we launch into the details, however, let's look at some basics of RMAN and try to understand why using RMAN is a good idea. Especially if you are new to RMAN, you might want to read this introduction.

Simply stated, RMAN is an excellent way to provide a physical backup of your Oracle database. This is in contrast to export/import and Data Pump, which provide logical backups. In all Oracle database versions, in addition to the Export and Import utilities, Oracle has provided a way of backing up an open database that is currently being used, provided the database is in ARCHIVELOG mode. Such a backup, known as a hot backup, is performed by backing up database files using an operating system utility such as tar in UNIX or OCOPY in Microsoft Windows after placing the associated tablespaces in BACKUP mode. When a tablespace is placed in this mode, the redo information being written to logs is changed to write whole blocks rather than just the changed information, as is done normally. The redolog files are copied out to archive logs when they are full. A physical backup of the database files, along with a backup of the archive logs, can then be used to re-create the database to a specified point in time.

In Microsoft Windows platforms, you will need to use the OCOPY command rather than the COPY command because the former can be used to back up files that have been opened by another process. Note that when a database is open, the data file would have been held open by the oracle.exe process.


Difference Between RMAN and Hot Backup

The reason full-block logging occurs when a tablespace is in BACKUP mode is to compensate for the difference between operating-system blocksize (normally 512 bytes) and the database blocksize (anywhere from 2KB to 32KB). This is a crucial difference between RMAN and the hot backup method. Full-block logging avoids a phenomenon known as fractured block read. In other words, the database could be writing an 8KB block as a whole, while the operating-system backup utility could have backed up an older version of a portion of the block in an earlier read. The next read would then read a modified version of another portion of the same block. The operating-system backup would have otherwise been inconsistent, except for the fact that the whole block, which was previously logged in redo, is written back during recovery. This makes the block consistent at recovery and thus avoids the fractured block read phenomenon. RMAN, on the other hand, is not an operating-system utility but an Oracle Databaseaware product. Hence, all reads by RMAN for the purpose of backup are performed using the block size of the database block itself, thus avoiding fractured block reads. When RMAN does encounter inconsistencies while reading blocks, RMAN notes these errors in the alert log and re-reads the block as may be required.

Although a few extra blocks of redo and ultimately more archive logs is normally not an issue in small, less-active databases, it quickly becomes a problem when the databases are large and more active. Larger databases usually mean tablespaces with a large number of large files that have to be kept for long periods in BACKUP mode, increasing the chances of extra redo related to backup. Large databases also normally support a large, active user community, and the amount of redo increases with activity. If you have this combination in a database, you should consider using RMAN to back up that database in order to avoid this extra overhead for redo during backups.

Advantages of RMAN over Hot Backup

RMAN also has other major advantages that are listed here. These advantages apply even if you are considering RMAN for versions below Oracle Database 10g.

  • RMAN provides for centralized management using an RMAN recovery catalog. Optionally, you can use RMAN in a NOCATALOG mode. When used with a recovery catalog, RMAN is quickly able to provide you with the names, locations, and versions of all the files backed up at any levelwhole database, tablespace, or data-file level. This information is also recorded in the control files in both cases. When operated in the NOCATALOG mode, the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the amount of time backup information is retained in the database's control files. This defaults to seven days and means that you cannot obtain backup information prior to this date when operating in the NOCATALOG mode.

  • RMAN backup and recovery actions can be scripted, so you can script all actions and prepare ahead of time for various recovery scenarios. These scripts work in a standard way across all platforms and servers, so you don't have to modify them for different operating systems and servers. RMAN scripts can be stored in a central RMAN catalog or on individual clients as operating-system files.

  • RMAN can be used from both the command line as well as from OEM, so it caters to beginners as well as advanced users.

  • RMAN supports incremental backups in the sense that only changed blocks are backed up. This can save an incredible amount of time and space for backup operations.

    CATALOG Versus NOCATALOG

    The issue of using RMAN with CATALOG and NOCATALOG is quite simple. The only down side of using an RMAN catalog is that you will need an instance for the catalog itself, either shared with another application or dedicated for just the RMAN catalog. When you manage only one or two databases and are using RMAN to back them up, it is probably not a good idea to use a catalog. If, however, you have a reasonably large number of databases being backed up via RMAN, it is probably a good idea to use a dedicated catalog database. If you are also implementing an OEM repository, then we recommend that you add the RMAN catalog into this database as well and make that database highly available, effectively killing two birds with one stone.

    Although RMAN is designed to work without a recovery catalog, if you choose not to use a recovery catalog, you must perform some additional administrative tasks. In any case, the backup-related information is retained in the database control files. The length of time this is retained is determined by CONTROL_FILE_RECORD_TIME_KEEP, which defaults to seven days. When a catalog is not being used, this value should be changed to reflect the length of time backups should be retained.


  • RMAN performs corrupt block detection for both database blocks and logs as it backs up. That way, you can be forewarned and take steps to fix the corruption before it affects recovery at a later date.

  • RMAN can perform backup of external but related files such as the initialization parameter file, password file, control files, and so on. You may have to script them separately using the other methods.

  • RMAN provides a media management layer (MML) that can be used to integrate RMAN backups to your tape backup systems such as ones by Legato or Tivoli. This prevents confusion and enables division of labor and responsibilities with the operations and system administration teams. Database administrators can, using the RMAN catalog, locate and request restoration of required files automatically, avoiding interfacing to another usually separate team. Optionally, RMAN can also write to a disk backup area and stage the backup and recovery operations from this location.

  • RMAN parallelizes backup using a concept known as channels. Backups can be produced in evenly sized packages known as backup sets.

  • RMAN does not back up unused portions of a data file. In other words, when you create a data file but haven't allocated blocks within it yet, the empty space will not be backed up, saving time and backup resources.

These reasons should be enough to convince you to move all your Oracle backups to RMAN, or at least consider using it in a few databases to begin with.

The only time we would recommend using hot backups is when using SAN (Storage Area Network) disk mirror technology such as EMC's BCV (Business Continuity Volume) or Hitachi Data Systems' ShadowImage to offload backup I/O onto the mirror copy rather than the production volumes. In this case, the whole database is placed in hot-backup mode and the mirror image is broken to produce a database image copy that can then be mounted back and backed up separately. This operation takes place in a matter of a few seconds, after which the tablespaces are again placed in normal mode. The amount of full-block redo is minimal in this case. This technique is well suited for large, active databases hosted on SANs that support such disk mirroring; you want to offload the backup I/O to the mirror copy.

Note that Oracle Database 10g supports the ALTER DATABASE BEGIN BACKUP and ALTER DATABASE END BACKUP commands to place the entire database in backup mode all at once. You will not have to code BEGIN BACKUP and END BACKUP per tablespace in this case.


For offline backups, RMAN needs a database to be mounted but not open. In the case of operating-system backups, an offline backup, also known as a cold backup, needs the database to be shut down and offline.

A Sample RMAN Backup Session

Running an RMAN backup is as simple as issuing a BACKUP DATABASE command, as shown in Listing 9.1. Commands entered by the user is shown in bold.

Listing 9.1. A Simple RMAN Backup

[View full width]

 $ rman Recovery Manager: Release 10.1.0.2.0 - 64bit Production Copyright (c) 1995, 2004, Oracle.  All rights reserved. RMAN> connect target; connected to target database: TS10G (DBID=845721274) using target database controlfile instead of recovery catalog RMAN> backup database; Starting backup at 07-MAY-05 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00003 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/sysaux01.dbf input datafile fno=00001 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/system01.dbf input datafile fno=00005 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/example01 .dbf input datafile fno=00002 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/undotbs01.dbf input datafile fno=00004 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/users01.dbf channel ORA_DISK_1: starting piece 1 at 07-MAY-05 channel ORA_DISK_1: finished piece 1 at 07-MAY-05 piece handle=/u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset /2005_05_07/o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:05:55 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset including current SPFILE in backupset channel ORA_DISK_1: starting piece 1 at 07-MAY-05 channel ORA_DISK_1: finished piece 1 at 07-MAY-05 piece handle=/u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset /2005_05_07/o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 07-MAY-05 RMAN> list backup; List of Backup Sets =================== BS Key  Type LV Size       Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 28      Full    3G         DISK        00:05:46     07-MAY-05          BP Key: 28   Status: AVAILABLE  Compressed: NO  Tag: TAG20050507T154504         Piece Name: /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G /backupset/2005_05_07/o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp   List of Datafiles in backup set 28   File LV Type Ckp SCN    Ckp Time  Name   ---- -- ---- ---------- --------- ----   1       Full 13802579   07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /system01.dbf   2       Full 13802579   07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /undotbs01.dbf   3       Full 13802579   07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /sysaux01.dbf   4       Full 13802579   07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /users01.dbf   5       Full 13802579   07-MAY-05 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G /example01.dbf BS Key  Type LV Size       Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 29      Full    2M         DISK        00:00:00     07-MAY-05          BP Key: 29   Status: AVAILABLE  Compressed: NO  Tag: TAG20050507T154504         Piece Name: /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G /backupset/2005_05_07/o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp   Controlfile Included: Ckp SCN: 13802773     Ckp time: 07-MAY-05   SPFILE Included: Modification time: 07-MAY-05 RMAN> sql 'alter system archive log current'; sql statement: alter system archive log current 

In this case, we did not connect to a RMAN catalog database. Instead, we connected to the target database that needed to be backed up. You can connect to this database named TS10G using the CONNECT TARGET command from the RMAN utility, which was invoked from the operating-system command line using the oracle account. This special account owns the software and the database, and thus did not need a user name and password to be able to log in to RMAN. The TS10G database was run in ARCHIVELOG mode and was open and active during the backup. Note that we did not have to use the BEGIN BACKUP and END BACKUP commands to place the tablespaces in hot-backup mode. The simple RMAN BACKUP DATABASE command was sufficient to execute the backup. We followed this up with a LIST BACKUP command that listed the current backups available.

RMAN backs up all the files needed for recovery in the event of a failure. RMAN's BACKUP command supports backing up these types of files:

  • Data files and image copies of data files

  • Control files and image copies of control files

  • Archived redo logs

  • Server parameter files

  • Backup pieces containing other backups created by RMAN

Other files needed for operation, such as network configuration files, password files, and the contents of the Oracle home, cannot be backed up with RMAN.

The backup can be stored as image copies as well as backup sets. Image copies are equivalent to operating-system copies of database and other files but are cataloged by RMAN and thus known to the system. A backup set is a logical structure that holds data from database files, control files, redologs, and archive files as well as system parameter files. A backup set consists of one or more physical files known as backup pieces. These files can be read only by RMAN and contain data multiplexed from one or more data files, control files, archivelog files, and redolog files. In Oracle Database 10g, all RMAN backup-related files are created in the flash recovery area by default. The backup set piece file created by the BACKUP DATABASE command can be seen in Listing 9.2.

Listing 9.2. Listing of RMAN Backup Pieces and File Sizes

[View full width]

 SQL> select file_name, bytes/1024/1024 size_mb   2  from dba_data_files; FILE_NAME                                                            SIZE_MB ----------------------------------------------------------------- ---------- /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/users01.dbf              5 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/sysaux01.dbf          2690 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/undotbs01.dbf           85 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/system01.dbf           590 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/example01.dbf          150                                                                   ---------- sum                                                                     3520 $ pwd /u04/app/oracle/product/10.1.0/db_1/flash_recovery_area/TS10G/backupset/2005_05_07 $ ls -lrt total 6309424 -rw-rw---- 1 oracle dba 3227467776 May  7 15:50 o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp -rw-rw---- 1 oracle dba    2949120 May  7 15:51 o1_mf_ncsnf_TAG20050507T154504_17t714dq_ .bkp 

If you match the names of the files in Listing 9.2 to the descriptive lines in Listing 9.1 that list the backup set information, you will notice that backup set piece file o1_mf_nnndf_TAG20050507T154504_17t6p13k_.bkp contains the database files and the backup set piece file o1_mf_ncsnf_TAG20050507T154504_17t714dq_.bkp contains the control file and system parameter file (SPFILE). Note that the size of the former is approximately 3,077MB, which is less than the total of the individual database sizes amounting to 3,520MB, as seen in Listing 9.2. The files are created in a subdirectory under the flash recovery area, appropriately identified by the database name (TS10G), the nature of the contents (namely backupset), and the date of the backup. You will learn more about Flashback technologies in Chapter 17, "Effectively Using Flashback Technologies," but suffice it to say that you may need to adjust the size of this area using the DB_RECOVERY_FILE_DEST_SIZE initialization parameter to a size that is adequate for both the intended size of backups to be retained as well as other files such as archivelog and flashback information.

You will also notice the words channel and tag. An RMAN channel is a logical name for the backup to be placed in. In this case, the default channel was a disk area named ORA_DISK_1 that defaulted to the flash recovery area. You can configure multiple RMAN channels to either disk or tape devices enabled via the MML, and they can be used in parallel. The tag is a user- or system-defined handle for the backup. You can use this as a key to track and locate this particular backup. In this case, the system-defined tag was a string containing the date and time of backup; this is actually a good tag to use. Finally, notice that you can always execute SQL commands from within RMAN using the SQL 'Your_SQL_command' option as seen at the end of Listing 9.1.

If you intend to use RMAN for backup, you will have to configure an adequate value for the LARGE_POOL_SIZE initialization parameter. RMAN uses this area for its buffering. If this is not configured, RMAN uses the shared pool instead for buffers. This can result in pollution of the library and data dictionary caches, leading to ORA-4031 errors.


RMAN Documentation

Documentation for RMAN has been strengthened in the documentation set for Oracle Database 10g. The following manuals should be perused for concepts, command references, and information about advanced topics:

  • Oracle Database 10g Recovery Manager Quick Start Guide. Read this first if you want a quick synopsis of RMAN. It also has a quick reference and is task-oriented. At 28 pages, it is indeed a quick read!

  • Oracle Database 10g Backup and Recovery Basics. This manual goes through the basics and concepts behind RMAN and is a prerequisite to the more advanced manuals noted next.

  • Oracle Database 10g Recovery Manager Reference. This manual is the RMAN-equivalent of the SQL command reference.

  • Oracle Database 10g Backup and Recovery Advanced User's Guide. This manual discusses in great detail concepts and advanced topics such as tuning and troubleshooting RMAN.

    After you become familiar with the basics of RMAN, this is a must-read. If you are already familiar with older versions of RMAN, this manual has a section that covers new RMAN features in Oracle Database 10g.

Accessing RMAN

RMAN can be accessed via both the command line, as seen in Listing 9.1, as well as using OEM Database Control. The backup/recovery commands in OEM can be accessed via the Maintenance tab. Certain simple operations related to RMAN can be performed from the following OEM screens:

  • Schedule Backup. In this screen, you can specify a backup strategy to use, the backup destination, and so on. You will have to specify operating-system credentials in order for the agent to log in and perform certain operations. Both an Oracle-suggested and a customized strategy can be chosen.

  • Perform Recovery. Simple restores and recoveries can be performed from this screen, including block recovery as well as data file and database restore and recovery.

  • Manage Current Backups. You can list, delete, delete obsolete, and perform various related operations for backup sets as well as image copies. In short, this screen can act as a GUI front end to many of the command-line actions required in RMAN.

  • Configure Backup Settings. In this screen, you can set the parallism, configure a backup location different from the default flash recovery area, choose the backup type (backup set, compress backup set, or image copy), as well as establish tape settings specific to the MML.

  • Configure Recovery Settings. This screen is not entirely connected to RMAN but is used for setting parameters that can affect RMAN. This includes the Mean Time To Recover (MTTR), archive log destinations, flash recovery area location and size, flashback logging, and flashback retention time. Note that you will have to be logged in as SYSDBA to perform these actions because the form needs to access and change the initialization parameters.

  • Configure Recovery Catalog Settings. In this screen, you can specify the details of the recovery catalog to be used for RMAN backup including the database name, schema, and password, as well as register the target database in the RMAN catalog.

We suggest you use these screens to set up your database initially for RMAN backup. Most of the screens also have a button to generate the RMAN script or the corresponding SQL so you can log what commands were executed in order to be able to record and repeat the actions when necessary.



    Oracle Database 10g Insider Solutions
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 672327910
    EAN: 2147483647
    Year: 2006
    Pages: 214

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net