Commonly performed operations, starting and exiting RMAN, configure RMAN environment, backup restore and recovery operations, and reporting with RMAN.

1. Starting and Existing RMAN

1

C:\RMAN

Connect to RMAN client with Target DB without recovery catalog

1
2
3
4
5
6
7

C:\RMAN TARGET SYS/SRDC@TEST1              
           OR
C:\RMAN TARGET SYS/SRDC@TEST1 NO CATALOG  
 
c:\RMAN CATALOG rman/cat@devdb        -- Connect to RMAN client with catalog
RMAN> CONNECT TARGET SYS/SRDC@TEST1;  -- Connect to Target DB
RMAN> CONNECT CATALOG rman/cat@devdb; -- Connect to catalog

Exit from RMAN client

1

RMAN> EXIT  

2. Configuring RMAN Environment

A number of RMAN settings can be persisted. Tthese settings will stay in effect between RMAN sessions. The show command to display the default RMAN settings:

View current RMAN configuration [SHOW ALL command]

RMAN> SHOW ALL
 
RMAN configuration parameters for database with db_unique_name DW are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\SNCFDEVTEST.ORA'; # default
RMAN>

Any parameters that are set to their default values have # default at the end of the configuration setting.

Configure Device Type and channels

By default RMAN allocates one disk channel for all operation automatically, and direct all backups to disk if no destination is specified RMAN uses the flash recovery area for all backups.

There is no need to allocate or deallocate a specific channel for backups unless you’re using a tape device. To Configure a tape device as follows:

1

RMAN> configure channel device type sbt  parms='ENV=(<vendor specific argu>)';

NOTE: sbt is the device type used for any tape backup subsystem, regardless of vendor.

Manual Channel allocation [ALLOCATE]
Manual channels always override automatic channels. must be used within a RUN block or ALLOCATE CHANNEL FOR MAINTENANCE at RMAN prompt.

1
2
3

RUN {  
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;  
BACKUP DATABASE PLUS ARCHIVELOG; }

RMAN allocates three channels for the device type when using automatic channels

1

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;

RMAN includes a "#default" comment at the end of the line if the RMAN default value has not been overridden.

1

CONFIGURE DEFAULT DEVICE TYPE TO disk;

Configure Retention Policy

Backups can be automatically retained and managed using one of two methods:

Recovery window
RMAN will retain as many backups as necessary.
For example, with a Recovery Window of seven days, RMAN will maintain enough image copies, incremental backups, and archived redo logs to ensure that the database can be restored and recovered to any point in time within the last seven days. Any backups that are not needed to support this recovery window are marked as OBSOLETE and are automatically removed by RMAN if a flash recovery area is used and disk space is needed for new backups.

Redundancy
Redundancy retention policy directs RMAN to retain the specified number of backups or copies of each datafile and control file. Any extra copies or backups beyond the number specified in the redundancy policy are marked as OBSOLETE. Obsolete backups are automatically removed if disk space is needed and a flash recovery area is used. Otherwise, you can use the delete obsolete command to remove the backup files and update the catalog.

If the retention policy is set to NONE, no backups or copies are ever considered obsolete, and the DBA must manually remove unneeded backups from the catalog and from disk.

Retention policy to a recovery window of four days

1

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

Retention policy to retains three backups of each datafile

1

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Delete Obsolete backup behind Retention policy

Delete old backups no longer required by the retention policy.

1

RMAN> DELETE OBSOLETE;

If flash recovery is set no need to perform this step. The DB automatically delete obsolete backups when space is needed.

Override the retentation policy

you can use KEEP option of the backup and change command to override the retentation policy for individual backups.

Configure Control File Autobackup

By default, the backup of the control file does not occur automatically. RMAN can be configured to back up the control file automatically either any time a successful backup must be recorded in the repository or when a structural change affects the contents of the control file

1

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Restoring default values

Reset any configure setting to its default with the CLEAR option.

RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR;
RMAN> CONFIGURE RETENTION POLICY CLEAR;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

Backup Compression

Backup can be compressed to save disk space. The files are decompressed automatically during a restore or recovery operation.

1

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

Compressing backupsets may not be necessary if the operating system’s file system has compression enabled or if the tape device hardware automatically compresses backups.

Initialization Parameters

A number of initialization parameters are used to control RMAN backups. Some more important parameters are.

CONTROL_FILE_RECORD_KEEP_TIME
A record of all RMAN backups is kept in the target control file. This parameter specifies the number of days that RMAN will attempt to keep a record of backups in the target control file. After this time, RMAN will begin to reuse records older than this retention period.

If RMAN needs to write a new backup record, and the retention period has not been reached, RMAN will attempt to expand the size of the control file. Usually, this is successful because the size of the control file is relatively small compared to other database objects. However, if space is not available for the expansion of the control file, RMAN will reuse the oldest record in the control file and write a message to the alert log.

As a rule of thumb, you should set CONTROL_FILE_RECORD_KEEP_TIME to several days beyond your actual recovery window to ensure that backup records are retained in the control file. The default is 7 days.

DB_RECOVERY_FILE_DEST
This parameter specifies the location of the flash recovery area. It should be located on a file system different from any database datafiles, control files, or redo log files, online or archived.

DB_RECOVERY_FILE_DEST_SIZE
The parameter DB_RECOVERY_FILE_DEST_SIZE specifies an upper limit to the amount of space used for the flash recovery area. The underlying file system may have less or more than this amount of space;

The parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE are both dynamic; they can be changed on the fly while the instance is running.

3. Preparing and Planning Database Restore and Recovery

You have to plan your database restore and recovery actions based on which database files have been lost and your recovery goal. RMAN can make most of the important decisions about the restore process for you, but you may want to preview and even override its decisions in some circumstances.

For example, if you know a given backup is unavailable, due to a tape being stored offsite or a device being inaccessible, you can direct RMAN to not use that backup during the restore process.

3.1. Database Restore and Recovery Procedure: Outline

1. Determine which database files must be restored from backup, and which backups.
2. Place the database in the state appropriate for the type of recovery that you are performing. For example, if you are recovering a single tablespace or datafile, then you can keep the database open and take the tablespace or datafile offline. If you are restoring all datafiles, then you must shut down the database and then mount it before you can perform the restore.
3. Restore lost database files from backup with the RESTORE command.
4. Perform media recovery on restored datafiles, if any, with the RECOVER command.
5. Perform any final steps required to make the database available for users again. For example, re-open the database if necessary, or bring offline tablespaces online.

3.2. Determining Which Database Files to Restore or Recover

Recognizing a Lost Control File

• The database shuts down immediately if any of the control file copies becomes inaccessible and reports an error.
• Loss of some but not all copies of your control file does not require recovery of the control file from backup.
• Copy an intact copy of the control file over the damaged or missing control file, OR update the parameter file so that does not refer to the damaged or missing control file.
• If control file restored from backup, media recovery of the whole database is required and then perform an OPEN RESETLOGS

Identifying Datafiles Requiring Recovery

To determine which if any files require media recovery using V$DATAFILE_HEADER, it does not detect all problems that require the datafile to be restored you can also query V$RECOVER_FILE to list datafiles requiring recovery by datafile number with their status and error information:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 1-Connect to the target database using SQL.
sqlplus 'SYS/srdc@devtest AS SYSDBA'
 
# 2-Determine the status of the database
SQL> SELECT STATUS FROM V$INSTANCE;
# If the status is OPEN, then, some datafiles may require media recovery.
 
# 3-Determine the status of datafiles headers:
SQL> COL FILE# FORMAT 999
SQL> COL STATUS FORMAT A7
SQL> COL ERROR FORMAT A10
SQL> COL TABLESPACE_NAME FORMAT A10
SQL> COL NAME FORMAT A30
 
SQL> SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME
     FROM V$DATAFILE_HEADER
     WHERE RECOVER = 'YES' OR (RECOVER IS NULL AND ERROR IS NOT NULL);

Each row returned a datafile that either requires media recovery or has an error requiring a restore. Check the RECOVER and ERROR columns.

• RECOVER file needs media recovery
• ERROR there was an error reading and validating the datafile header.
  
  -If ERROR is not NULL, then the datafile header cannot be read and validated.
  Check for a temporary hardware or operating system problem causing the error. If there is no such problem, you must restore the file or switch to a copy.
  
  -If the ERROR column is NULL and the RECOVER column is YES, then the file requires media recovery (and may also require a restore from backup).

Example-2 [V$RECOVER_FILE]

• You can not use V$RECOVER_FILE with a control file restored from backup or a control file that was re-created.
• A restored or re-created control file does not contain the information needed to update V$RECOVER_FILE accurately.

1
2

SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM V$RECOVER_FILE;

Example-3 [V$DATAFILE and V$TABLESPACE]

To find datafile and tablespace names, that requires recovery using V$DATAFILE and V$TABLESPACE views. For example:

1
2
3
4
5
6
7
8
9
10
11
12

COL DF# FORMAT 999
COL DF_NAME FORMAT A35
COL TBSP_NAME FORMAT A7
COL STATUS FORMAT A7
COL ERROR FORMAT A10
COL CHANGE# FORMAT 99999999
 
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;

The ERROR column identifies the problem for each file requiring recovery.

Recovery of Read-Only Tablespaces

• Recovery is not needed on any read-only tablespace during crash or instance recovery.
• If you restore a read-only tablespace from a backup taken before the tablespace was made read-only, then you cannot access the tablespace until you perform media recovery on it.

3.3. Determining your DBID

In disaster recovery when you have lost all database files, you will need to use your DBID. DBID should be recorded along with other basic information.

There are two places where you can find it without opening your database.

• DBID is the part of filename of control file auto-backup. Locate file
• Any RMAN saved session. DBID is displayed by the RMAN client when it starts up and connects to your database

1

RMAN> connected TO target DATABASE: RDBMS (DBID=774627068) 

3.4. Previewing Backups Used in Restore Operations

Use RESTORE... PREVIEW when planning your restore and recovery operation, to ensure that all required backups are available

RESTORE... PREVIEW

Creates a detailed report of every backup to be used in the requested RESTORE operation. Some examples are;

1
2
3
4
5
6

RMAN> RESTORE DATABASE PREVIEW;
RMAN> RESTORE TABLESPACE users PREVIEW;
RMAN> RESTORE DATAFILE 3 PREVIEW;
RMAN> RESTORE ARCHIVELOG FROM LOGSEQ 200 PREVIEW;
RMAN> RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW;
RMAN> RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW;

RESTORE... PREVIEW output is in the same format as the output of the LIST command.

RESTORE... PREVIEW SUMMARY

Use the RESTORE... PREVIEW SUMMARY option to suppress much of the detail.

1
2
3
4
5
6

RMAN> RESTORE DATABASE PREVIEW SUMMARY;
RMAN> RESTORE TABLESPACE users PREVIEW SUMMARY;
RMAN> RESTORE DATAFILE 3 PREVIEW SUMMARY;
RMAN> RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW SUMMARY;
 
 

RESTORE... PREVIEW output is in the same format as the output of the LIST command.

RESTORE... PREVIEW RECALL

RESTORE... PREVIEW RECALL can be used with any RESTORE operation, in cases a restore fails due to a needed backup being stored remotely.

RMAN> restore archivelog ALL preview;

The "List of remote backup files" at the end of the output identifies the backups that are stored remotely. In such a case, using RESTOREARCHIVELOG ALL PREVIEW RECALL initiates recall for the remote backups

1

RMAN> restore archivelog ALL preview recall;

You can append RECALL to any RESTORE... PREVIEW command, as in these examples:

1
2
3

RMAN> RESTORE TABLESPACE users PREVIEW RECALL;
RMAN> RESTORE DATAFILE 3 PREVIEW RECALL;
 

4. Validating the Restore of Backups

The RESTORE ... VALIDATE and VALIDATE BACKUPSET commands test whether you can restore from your backups. You can test the availability of usable backups for any desired RESTORE operation, or test the contents of a specific backup for use in RESTORE operations.

RMAN decides which backup sets, datafile copies, and archived logs are needed for the operation, and scans them to verify that they are usable. For example:

Validating with RESTORE ... VALIDATE

RESTORE ... VALIDATE tests whether RMAN can restore a specific object from a backup. RMAN chooses which backups to use.

• When validating backups with RESTORE... VALIDATE, the database can be mounted or open.
• You do not have to take datafiles offline when validating the restore of datafiles, because validation of backups of the datafiles only reads the backups and does not affect the production datafiles.

1
2
3
4

RMAN> RESTORE CONTROLFILE VALIDATE;
RMAN> RESTORE TABLESPACE SYSTEM VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE;
RMAN> RESTORE DATAFILE 4,5,6 VALIDATE; 

If you see error messages in the output and the following message, then RMAN cannot restore one or more of the specified files from your available backups:

1

RMAN-06026: some targets NOT found - aborting restore

If you see an error message stack and output similar to the following, for example, then RMAN encountered a problem reading the specified backup:

1
2
3
4

RMAN-03009: failure of restore command ON c1 channel at 12-DEC-01 23:22:30
ORA-19505: failed TO identify file "oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable TO obtain file STATUS SVR4
Error: 2: No such file OR directory Additional information: 3

Validating With VALIDATE BACKUPSET

VALIDATE BACKUPSET tests the validity of a backup set that you specify

The BACKUP VALIDATE command requires that you know the primary keys of the backup sets that you want to validate.

To specify which backup sets to validate: Find the backup sets that you want to validate by running LIST commands, noting primary keys. For example:

1

RMAN> LIST BACKUP; 

Validate the restore of the backup sets, referencing them by the primary keys. This example validates the restore of backup sets 56 and 57:

1

RMAN> VALIDATE BACKUPSET 56,57;

If the output contains the message " validation complete", then RMAN successfully validated the restore of the specified backup set. For example:

1
2
3
4
5

USING channel ORA_DISK_1
channel ORA_DISK_1: starting validation of archive log backupset
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle/dbs/0mdg9v8l_1_1 tag=TAG20020208T155604 params=NULL
channel ORA_DISK_1: validation complete 

In the following example, we will validate the entire database along with the archived redo logs after one of the redo log files is accidentally lost:

1

RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

5. Backup Operations

RMAN BACKUP command is used to backup oracle database files and datafiles. you can make backups as image copies or as backupsets. BACKUPSET is default if you do not specify.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

BACKUP AS COPY         --Make backup as image copies
BACKUP AS BACKUPSET    --Make backups as backup sets
 
RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
 
--[Backing up Archive log]--
RMAN>BACKUP ARCHIVELOG COMPLETION TIME BETWEEN 'SYSDATE-31' AND 'SYSDATE-7';

--[Backing up TableSapce]--
RMAN> BACKUP TABLESPACE system, users, tools;
 
--[Backing up Datafiles]--
RMAN> BACKUP AS BACKUPSET DATAFILE
'ORACLE_HOME/oradata/trgt/users01.dbf',
'ORACLE_HOME/oradata/trgt/tools01.dbf';
 
RMAN> BACKUP DATAFILE 1,3,5;
 
--[Backing up Control file]--
RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';
 
--[Backing up Spfile]--
RMAN> BACKUP SPFILE;
 
--[Backing up Whole database]--
RMAN> BACKUP BACKUPSET ALL

5.1. Full Database Backups

in this example We’ll use backupsets to copy all database files, including the SPFILE, to the flash recovery area

1
2
3
4
5
6
7

RMAN> BACKUP AS BACKUPSET DATABASE SPFILE;
 
-- ensures that we have archived logs for all transactions, including those
-- that occurred while the backup was taking place; this ensures that we can 
-- perform media recovery after restoring this backup
 
RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';

If control file autobackup is set to on (configure controlfile autobackup = on) then we don’t need to specify SPFILE in the backup command.

Make consistent backup ( database is not open No archive log mode)Tablespace Backups

1
2
3
4
5

RMAN> SHUTDOWN IMMEDIATE    --(to shutdown database)
RMAN> STARTUP MOUNT;
RMAN> BACKUP DATABASE;      --(to backup database, no need to backup 
                            -- archived log as database is not open)
RMAN> ALTER DATABASE OPEN;  --(To Open Database)

To backup database and archived redo while system is Up (Hot Backup) Database should be in archive log mode

1

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

5.2. Tablespace Backups

You might back up an individual tablespace in a database that is too large to back up all at once; creating a backupset or image copy of a tablespace at frequent intervals will reduce the amount of redo that would need to be applied to an older backup of the tablespace in the event of media failure.

For example, in an environment with three large tablespaces—USERS, USERS2, and USERS3—along with the default tablespaces SYSTEM and SYSAUX, you might back up the SYSTEM and SYSAUX tablespaces on Sunday, USERS on Monday, USERS2 on Wednesday, and USERS3 on Friday.

Failures of any media containing datafiles from one of these tablespaces will use a tablespace backup that is no more than a week old plus the intervening archived and online redo log files for recovery.

From an RMAN session, we will back up the tablespace along with the control file. In this case, it’s critical that we back up the control file because it contains the definition for the new tablespace.

1
2

RMAN> REPORT SCHEMA; --to know the name of tablespace recently added
RMAN> BACKUP AS BACKUPSET TABLESPACE <TABLESPACE NAME>;

5.3. Datafiles Backups

Individual datafiles can be backed up as easily as we can back up a tablespace. you can back up individual datafiles within a tablespace over a period of days, and the archived redo log files will take care of the rest during a recovery operation. Here is an example of a datafile backup of a single datafile.

1

RMAN> BACKUP AS BACKUPSET DATAFILE  '/U04/ORADATA/ORD/OE_TRANS_06.DBF';

5.4. Image Copies

Image copies make bit-for-bit copies of the specified tablespace or entire database. There are a couple of distinct advantages for using RMAN to perform image copy backups:

• First, the backup is automatically recorded in the RMAN repository.
• Second, all blocks are checked for corruption as they are read and copied to the backup destination.
• Another side benefit to making image copies is that the copies can be used “as is” outside of RMAN if, for some reason, a recovery operation must occur outside of RMAN.
• Image copies can only be created on DISK device types.

Another backup of the INET_STAR tablespace, this time as an image copy:

1

RMAN> BACKUP AS COPY TABLESPACE INET_STAR;

5.5. Backup Options

Here are some often used BACKUP command options.

The following BACKUP commands illustrate these options:

1
2
3

RMAN> BACKUP FORMAT='AL_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';
RMAN> BACKUP TAG 'weekly_full_db_bkup' DATABASE MAXSETSIZE 10M;
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;

5.6. Control File, SPFILE Backup

To back up the control file and SPFILE manually, use the following RMAN command:

1

RMAN> BACKUP CURRENT CONTROLFILE SPFILE;

5.7. Archived Redo Logs backup

We want to back up copies of the logs to tape or another disk destination. Once the backup is completed, we have the option to leave the logs in place, to delete only the logs that RMAN used for the backup, or to delete all copies of the archived logs that were backed up to tape.

In the following example, we back up all the archived log files in the flash recovery area and then remove them from disk:

1

RMAN> BACKUP DEVICE TYPE SBT ARCHIVELOG ALL DELETE INPUT;

If archived log files are being sent to multiple locations, then only one set of the archived redo log files are deleted. If we want all copies to be deleted, we use delete all input instead of delete input.

Backing up and deleting only older archived redo log files can be accomplished by specifying a date range in the backup archivelog command:

1
2

RMAN> BACKUP DEVICE TYPE SBT ARCHIVELOG FROM TIME 'SYSDATE-30' 
      UNTIL TIME 'SYSDATE-7' 3> DELETE ALL INPUT;

In the preceding example, all archived redo logs older than one week, going back for three weeks, are copied to tape and deleted from disk. In addition, you can specify a range using SCNs or log sequence numbers.

5.8. Incremental Backups

When a number of different types of backups exist in the catalog, such as image copies, tablespace backupsets, and incremental backups, RMAN will choose the best combination of backups to most efficiently recover and restore the database.

The decision whether to use cumulative or differential backups is based partly on where you want to spend the CPU cycles, and how much disk space you have available.

Using cumulative backups means that each incremental backup will become progressively larger and take longer until another level 0 incremental backup is performed, but during a restore and recover operation, only two backupsets will be required.

On the other hand, differential backups only record the changes since the last backup, so each backupset might be smaller or larger than the previous one, with no overlap in data blocks backed up.

We find out that several files are outside of our retention policy of four days; in other words, files that need more than four days worth of archived redo logs to recover the database:

1

RMAN> REPORT NEED BACKUP;

To set up our incremental policy, we need to perform a level 0 incremental backup first:

1

RMAN> BACKUP INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE;

At any point in the future after this level 0 backup, we can perform an incremental level 1 differential backup:

1

RMAN> BACKUP AS COMPRESSED BACKUPSET  INCREMENTAL LEVEL 1 DATABASE;

The default incremental backup type is differential; the keyword differential is neither needed nor allowed. However, to perform a cumulative backup, we add the cumulative keyword:

1

RMAN> BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

In an OLTP environment with heavy insert and update activity, incremental backups may be more manageable in terms of disk space usage. For a data warehouse environment with infrequent changes, a differential backup policy may be more suitable

1

RMAN> REPORT NEED BACKUP;

Incremental level 0 & 1 database backup example

1
2

RMAN> BACKUP INCREMENTAL LEVEL0 DATABASE; (For incremental level 0 backup)
RMAN> BACKUP INCREMENTAL LEVEL1 DATABASE; (For incremental level 1 backup)

Incremental Backup Block Change Tracking

Another way to improve the performance of incremental backups is to enable block change tracking. For a traditional incremental backup, RMAN must inspect every block of the tablespace or datafile to be backed up to see if the block has changed since the last backup. For a very large database, the time it takes to scan the blocks in the database can easily exceed the time it takes to perform the actual backup.

By enabling block change tracking, RMAN knows which blocks have changed by using a change tracking file. Although there is some slight overhead in space usage and maintenance of the tracking file every time a block is changed, the tradeoff is well worth it if frequent incremental backups are performed on the database.

1

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA';

The dynamic performance view V$BLOCK_CHANGE_TRACKING contains the name and size of the block change tracking file as well as whether change tracking is enabled:

1

SQL> SELECT FILENAME, STATUS, BYTES FROM V$BLOCK_CHANGE_TRACKING;

5.9. Backup Compression

We can either configure backup compression as the default for backupsets or explicitly specify compression in an RMAN backup command

1

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;

5.10. Using Flash Recovery Area

To facilitate a completely disk-based recovery scenario, the flash recovery area should be big enough for a copy of all datafiles, incremental backup files, online redo logs, archived redo logs not on tape, control file autobackups, and SPFILE backups.

The dynamic performance view V$RECOVERY_FILE_DEST displays information about the number of files in the flash recovery area, how much space is currently being used, and the total amount of space available in the flash recovery area.

if the database is in ARCHIVELOG mode, and a flash recovery area is defined, then the initialization parameter LOG_ARCHIVE_DEST_10 is implicitly defined as the flash recovery area.

Multiple databases can share the same flash recovery area, even a primary and a standby database. Even with the same DB_NAME, as long as the DB_UNIQUE_NAME parameter is different, there will not be any conflicts. RMAN uses the DB_UNIQUE_NAME to distinguish backups between databases that use the same flash recovery area.

6. Restore and Recovery operations

Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical database files. Restoring datafiles is retrieving them from backups as needed for a recovery operation. Recovery is the application of changes from redo logs and incremental backups to a restored datafile, to bring the datafile to a desired SCN or point in time.

RMAN can perform various restore and recovery operations, and most of these operations can be performed while the database is open and available to users.

6.1. Block Media Recovery

RMAN can perform block media recovery rather than a full datafile recovery. While block media recovery is in progress, the affected datafiles can remain online and available to users.

There are a number of ways in which block corruption is detected. During a read or write operation from an insert or select statement, Oracle may detect a block is corrupt, write an error in a user trace file, and abort the transaction.

An RMAN backup or backup validate command can record corrupted blocks in the dynamic performance view V$DATABASE_BLOCK_CORRUPTION.

In addition, the SQL commands analyze table and analyze index could uncover corrupted blocks.
To recover one or more data blocks, RMAN must know the datafile number and block number within the datafile. This information is available in a user trace file, as in the following example:

ORA-01578: ORACLE DATA BLOCK CORRUPTED (FILE # 6, BLOCK # 403)
ORA-01110: DATA FILE 6: '/U09/ORADATA/ORD/OE_TRANS01.DBF'
 
RMAN> RECOVER DATAFILE 6 BLOCK 403;
 
# to recover all corrupted blocks
RMAN> BLOCKRECOVER CORRUPTION LIST;
 
# You can also recover individual blocks
RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 233, 235 DATAFILE 4 BLOCK 101; 

NOTE: The blockrecover command, available in previous releases of RMAN, has been deprecated in Oracle Database 11g in favor of the recover command; the syntax of the command is otherwise the same.

6.2. Restoring a Control File

Loss or corruption of all copies of your control file requires restore of the control file from backup.
After restoring the control files of your database from backup, you must perform complete media recovery of the database and then open your database with the RESETLOGS option

Restore the control file to its default location defined in the CONTROL_FILES initialization parameter

1

RMAN> RESTORE CONTROLFILE

If you are not using a recovery catalog, you can add the from ‘<filename>’ clause to the command to specify where the latest control file exists:

1

RMAN> RESTORE CONTROLFILE FROM '/U11/ORADATA/ORD/BKUP.CTL';

Restore of the Control File from Control File Autobackup

If you are not using a recovery catalog, you must restore your control file from an autobackup.
If you want to restore the control file from autobackup, the database must be in a NOMOUNT state.

You must first set the DBID for your database, and then use the RESTORE CONTROLFILE FROM AUTOBACKUP command:

1
2
3
4
5
6

RMAN> SET DBID 320066378;
RMAN> RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE CONTROLFILE FROM AUTOBACKUP;
}

To determine the correct value for autobackup_format, see the description of CONFIGURE CONTROLFILE AUTOBACKUP FORMAT in the entry for CONFIGURE.

Restore of the Control File When Using a Flash Recovery Area

if you are using a flash recovery area, RMAN updates a control file restored from backup, by performing an implicit crosscheck of all disk-based backups and image copies listed in the control file, and cataloging any backups in the flash recovery area that are not recorded in the restored control file. As a result the restored control file has a complete and accurate record of all backups in your flash recovery area and any other backups that were known to the control file at the time of the backup.

Tape backups are not automatically crosschecked after the restore of a control file. After restoring the control file and mounting the database you must crosscheck the backups on tape:

1

RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;

Restoring a Control File When Using a Recovery Catalog

You do not have to specify your DBID or control file autobackup format.

1
2

% rman TARGET rman/rman CATALOG catdb/catdb
RMAN> RESTORE CONTROLFILE;

The restored control file is written to all locations listed in the CONTROL_FILES initialization parameter.

Restore of the Control File From a Known Location

The control file copy found at the location specified by filename will be written to all locations listed in the CONTROL_FILES initialization parameter.

1

RMAN> RESTORE CONTROLFILE FROM 'filename';

Restore of the Control File to a New Location

There are two ways.

CONTROL_FILES initialization parameter

• 1. Edit CONTROL_FILES initialization parameter to new locations
  2. RESTORE CONTROLFILE command with no arguments to restore the control file to the default locations

RESTORE CONTROLFILE TO 'new location'

1

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

You can perform this operation with the database in NOMOUNT, MOUNT or OPEN states, because you are not overwriting any of the control files currently in use.

6.3. Restoring the Server Parameter File (SPFILE) from Backup

if you lose your server parameter file (SPFILE), RMAN can restore it to its default location or to a location of your choice.

Unlike the loss of the control file, the loss of your SPFILE does not cause your instance to immediately stop. Your instance may continue operating, although you will have to shut it down and restart it after restoring the SPFILE.

Note the following when restoring the SPFILE:

• If the instance is already started with the server parameter file, then you cannot overwrite the existing server parameter file.
• When the instance is started with a client-side initialization parameter file, RMAN restores the SPFILE to the default SPFILE location if the TO clause is not used. The default location is platform-specific
• Restoring the SPFILE is one situation in which a recovery catalog can simplify your recovery procedure, because you can avoid the step of having to record and remember your DBID. This procedure assumes that you are not using a recovery catalog.

To restore the server parameter file:

If the database is up at the time of the loss of the SPFILE.

1

RMAN TARGET /

If the database is not up when the SPFILE is lost, and you are not using a recovery catalog, then you must set the DBID of the target database.
Shut down the instance and restart it without mounting. When the SPFILE is not available, RMAN starts the instance with a dummy parameter file. For example:

1

RMAN> STARTUP FORCE NOMOUNT;

Restore the server parameter file. If restoring to the default location, then run:

1

RMAN> RESTORE SPFILE FROM AUTOBACKUP;

If restoring to a nondefault location, then you could run commands as in the following example:

1

RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM AUTOBACKUP;

Restart the instance with the restored file. If restarting with a server parameter file in a nondefault location, then create a new client-side initialization parameter file with the single line SPFILE=new_location, where new_location is the path name of the restored server parameter file. Then, restart the instance with the client-side initialization parameter file.

For example, create a file /tmp/init.ora which contains the single line:

1

SPFILE=/tmp/spfileTEMP.ora

Then use this RMAN command, to restart the instance based on the restored SPFILE:

1

RMAN> STARTUP FORCE PFILE=/tmp/init.ora; # startup with /tmp/spfileTEMP.ora

Restore of the SPFILE from the Control File Autobackup
If you have configured control file autobackups, the SPFILE is backed up with the control file whenever an autobackup is taken.

If you want to restore the SPFILE from the autobackup, you must first set the DBID for your database, and then use the RESTORE SPFILE FROM AUTOBACKUP command. The procedure is similar to restoring the control file from autobackup. You must first set the DBID for your database, and then use the RESTORE CONTROLFILE FROM AUTOBACKUP command:

1
2
3
4
5
6

RMAN> SET DBID 320066378;
RMAN> RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE SPFILE FROM AUTOBACKUP;
}

Creating a Client-Side Initialization Parameter File (PFILE) with RMAN
You can also restore the server parameter file as a client-side initialization parameter file. The filename you specify should be on a file system accessible from the host where the RMAN client is running. This file need not be accessible directly from the host running the instance.

1
2
3
4
5
6

RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';
 
#To restart the instance using the client-side PFILE if RMAN is 
## running on the same client machine:
RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora';
 
 

6.4. Restoring & Recover an Entire Database

In the following scenario, we have lost all datafiles control file and online redo log files are available

1

C:\RMAN TARGET / CATALOG RMAN/RMAN@RAC

#open the database in mount mode
RMAN> STARTUP FORCE MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

To limit the amount of disk space used during a recovery operation, the recover command used in the previous example could use the following options instead:

1

RMAN> RECOVER DATABASE DELETE ARCHIVELOG;

To skip certain tablespaces while recovering the rest of the database

1

RMAN> RECOVER DATABASE SKIP TABLESPACE users;

6.5. Restoring & Recover a Tablespace or Datafile

Restoring and recovering a datafile is a very similar operation to restoring a tablespace. Once the missing or corrupted datafile is identified using the V$DATAFILE_HEADER view; the tablespace is taken offline, the datafile(s) are restored and recovered, and the tablespace is brought back online. If only file number 7(USERS tablespace) was lost recovery of the tablespace is possible while the database remains open and available, the recover and restore commands are as simple as this:

1

SQL> SELECT FILE#, STATUS, ERROR, TABLESPACE_NAME, NAME FROM V$DATAFILE_HEADER;

The alert log would give you another clue the next time you tried to start the database with a missing or corrupted datafile:

1
2

ORA-01157: CANNOT IDENTIFY/LOCK DATA FILE 4 - SEE DBWR TRACE FILE
ORA-01110: DATA FILE 4: '+DATA/DW/DATAFILE/USERS.259.630244583'

After replacing the disk drive, we initiate an RMAN session and find out that file number 7 corresponds to the USERS tablespace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

RMAN> REPORT SCHEMA;
 
#Force tablespace offline
RMAN> SQL 'ALTER TABLESPACE USERS OFFLINE IMMEDIATE';
 
#Copy latest image of datafile to their orignal location
RMAN> RESTORE TABLESPACE USERS;
 
#Applied redo form redo log
RMAN> RECOVER TABLESPACE USERS;
 
#Force tablespace back again online
RMAN> SQL 'ALTER TABLESPACE USERS ONLINE';
 
OR
 
RMAN> SQL 'ALTER DATABASE DATAFILE 7 OFFLINE';
RMAN> RESTORE DATAFILE 7;
RMAN> RECOVER DATAFILE 7;
SQL 'ALTER DATABASE DATAFILE 7 ONLINE';

RMAN will restore from backup any archived redo logs required during the recovery operation. If backups are stored on a media manager.

One very useful option in managing disk space associated with these restored files is the DELETE ARCHIVELOG option, which causes the deletion of restored archived redo logs from disk once they are no longer needed for the RECOVER operation:

1

RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG;

Note that when RMAN restores archived redo log files to the flash recovery area in order to perform a RECOVER operation, the restored logs are automatically deleted after they are applied to the datafiles, even if you do not use the DELETE ARCHIVELOG option.

if two datafile or tablespace are missing

1

RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf';

6.6. Restoring Archived Redo Logs from Backup

RMAN will restore archived redo log files from backup automatically as needed to perform recovery.

However, you can also restore archived redo logs manually if you wish, in order to save the time needed to restoroe these files later during the RECOVER command, or if you want to store the restored archived redo log files in some new location.

By default, RMAN restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and the LOG_ARCHIVE_DEST_1 parameters of the target database.

Restoring Archived Redo Logs to a New Location
You can override the default location for restored archived redo logs with the SET ARCHIVELOG DESTINATION command. This command manually stages archived logs to different locations while a database restore is occurring. During recovery, RMAN knows where to find the newly restored archived logs; it does not require them to be in the location specified in the initialization parameter file.

To restore archived redo logs to a new location:

1
2
3
4
5
6
7
8
9
10
11
12
13

C:\ RMAN TARGET SYS/SRDC@DEVTEST # database is mounted or open
RUN
{ 
#Specify the new location for the restored archived redo logs
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
 
#Restore the archived redo logs.
RESTORE ARCHIVELOG ALL;
# restore and recover datafiles as needed
.
.
.
}

Restoring Archived Redo Logs to Multiple Locations

You can specify restore destinations for archived logs multiple times in one RUN block, in order to distribute restored logs among several destinations. (You cannot, however specify multiple destinations simultaneously to produce multiple copies of the same log during the restore operation.) You can use this feature to manage disk space used to contain the restored logs.

This example restores 300 archived redo logs from backup, distributing them across the directories /fs1/tmp, /fs2/tmp, and /fs3/tmp:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

RUN 
{ 
# Set a new location for logs 1 through 100.
SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
# Set a new location for logs 101 through 200.
SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
# Set a new location for logs 201 through 300.
SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
# restore and recover datafiles as needed
.
.
.
}

When you issue a RECOVER command, RMAN finds the needed restored archived logs automatically across the destinations to which they were restored, and applies them to the datafiles.

6.7. Data Recovery Adviser

In a busy DBA's schedule, you may be aware of a database failure (usually from a user's phone call or e-mail), but you don't know the specific cause; using the Data Recovery Advisor, new to Oracle Database 11g, you can zoom in on the failure without checking the alert log or trace files.

The Data Recovery Advisor is available at the RMAN command line or in Oracle Enterprise Manager, as you'll see in the following paragraphs.

In this scenario, the datafile for the tablespace XPORT_DW was accidentally deleted by the system administrator; the next time one of the users tries to create a table in this tablespace, they get this message:

1
2
3
4
5
6

SQL> CREATE TABLE DAILY_LINEITEM
TABLESPACE XPORT_DW
AS SELECT * FROM OE.LINEITEM_TABLE;
 
ERROR AT LINE 3:
ORA-01658: UNABLE TO CREATE INITIAL EXTENT FOR SEGMENT IN TABLESPACE XPORT_DW

You get an instant message from the user notifying you of the failure, and since you're already at the RMAN command-line interface, you use the list failure command to see what the problem might be:

1
2
3
4
5
6
7

RMAN> LIST FAILURE;
 
List of DATABASE Failures
=========================
Failure ID Priority STATUS Time Detected Summary
---------- -------- --------- ------------- -------
1022 HIGH OPEN 05-SEP-07 One OR more non-system datafiles are corrupt

There is only one failure, so you drill down into the failure using the Failure ID and the detail option of the list failure command:

1
2
3
4
5
6
7

RMAN> LIST FAILURE 1022 DETAIL;
RMAN> ADVISE FAILURE;
 
RMAN> SQL 'ALTER DATABASE DATAFILE 9 OFFLINE';
RMAN> RESTORE DATAFILE 9;
RMAN> RECOVER DATAFILE 9;
RMAN> SQL 'ALTER DATABASE DATAFILE 9 ONLINE';

7. Reporting of RMAN Operations

The RMAN LIST and REPORT commands, generate reports on backup activities based on the RMAN repository. Use SHOW ALL to display the current RMAN configuration.

7.1. Listing Backups

Run the LIST BACKUP and LIST COPY commands to display informatio.

1
2
3
4
5

RMAN> LIST BACKUP OF DATABASE;
RMAN> LIST COPY OF DATAFILE 1, 2, 3;
RMAN> LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 1437;
RMAN> LIST CONTROLFILECOPY "/tmp/cf.cpy";
RMAN> LIST BACKUPSET OF DATAFILE 1;

For backups, you can control the format of LIST output with these options:

For both backups and copies you have the following additional options:

7.2. Reporting on Database Files and Backups

The REPORT command performs more complex analysis than LIST. Some of the main options are:

7.3. Monitoring RMAN Through V$ Views

Status information for jobs in progress and completed jobs is stored in V$RMAN_STATUS. V$RMAN_OUTPUT contains the text ouptut of all RMAN jobs.

To see status information on jobs in V$RMAN_STATUS use the following query:

1

SQL> SELECT OPERATION,STATUS,MBYTES_PROCESSED,START_TIME,END_TIME FROM V$RMAN_STATUS;

To correlate a channel with a process, run the following query in SQL*Plus while the RMAN job is executing:

1
2
3
4
5
6
7
8

SQL> COLUMN CLIENT_INFO FORMAT a30
SQL> COLUMN SID FORMAT 999
SQL> COLUMN SPID FORMAT 9999
 
SQL> SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM V$PROCESS p, V$SESSION s
WHERE p.ADDR = s.PADDR
AND CLIENT_INFO LIKE 'rman%';

To calculate the progress of an RMAN job, run the following query in SQL*Plus while the RMAN job is executing:

SQL> SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
ROUND(SOFAR/TOTALWORK*100,2) "% COMPLETE"
FROM V$SESSION_LONGOPS 
WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%' 
AND TOTALWORK != 0 AND SOFAR <> TOTALWORK;

 

8. RMAN and Scripting and Logfile

RMAN supports the use of stored scripts and command files to help manage recurring tasks. The RMAN RUN command provides a degree of flow-of-control in your scripts.

Command Files

A command file is a text file which contains RMAN commands as you would enter them at the command line. You can run the command file by specifying its name on the command line. If the LOG command line argument is specified, RMAN directs output to the named log file. Command files are one way to automate scheduled backups through an operating system job control facility.

RMAN TARGET / CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG outfile.txt

Stored Scripts

• Stored scripts stores sequence of RMAN commands.
• Always available to any RMAN client that can connect to the database and catalog.
• Scripts can be local or global (associated with target DB / can be run against any target DB).
• To work with stored scripts u must be connect with both target DB and recovery catalog.

Commands Valid Only in RUN Blocks

There are RMAN commands which are only valid in RUN blocks. These typically involve setting up the environment within which the statements in the RUN block will execute.

1
2

ALLOCATE CHANNEL 
SET NEWNAME FOR DATAFILE.

Commands Not Valid in RUN Blocks

There are a number of RMAN commands which cannot be used in RUN blocks. Typically these are used to control the RMAN environment

1
2
3
4
5
6

CONNECT
CONFIGURE
CREATE CATALOG, DROP CATALOG, UPGRADE CATALOG
CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT
LIST
REPORT

You can include these commands inside command files, as long as they are not wrapped inside a RUN block. You cannot use them inside a stored script from the recovery catalog, because the contents of a stored script are executed within a RUN block.

RMAN Output to a Log File

RMAN client sends the output to the terminal. If LOG option specified, then output is written to a log file instead.

1
2

V$RMAN_OUTPUT VIEW   currently executing RMAN jobs
V$RMAN_STATUS VIEW   contains metadata about jobs IN progress & completed jobs

Operations of Stored Scripts

Connect with target DB and catalog

1
2

RMAN> CONNECT TARGET SYS/SRDC@TEST1       -- connect with target database
RMAN> CONNECT CATALOG RMAN/CAT@DEVDB      -- connect with recovery catalog

1
2
3
4
5
6
7
8
9
10
11
12

CREATE SCRIPT full_backup            --Create local script
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}

--Create global script with comments 
CREATE GLOBAL SCRIPT global_full_backup    
COMMENT 'use only with ARCHIVELOG mode databases'
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}

Create local or global scripts and read contents form text file. File must be start with { and end with a } CREATE SCRIPT full_backup FROM FILE 'my_script_file.txt';

1
2
3
4
5
6
7
8
9
10

RUN { EXECUTE SCRIPT           --Execute local script
full_backup ; }
 
RUN { EXECUTE GLOBAL SCRIPT    --Execute Global script 
global_full_backup ; }
OR
RUN { EXECUTE SCRIPT global_
full_backup
; }
 

1
2
3
4

PRINT SCRIPT full_backup;                -- display local script
PRINT GLOBAL SCRIPT global_full_backup;  -- display global script

-- send contents to file
PRINT GLOBAL SCRIPT global_full_backup TO FILE 'my_script_file.txt';   
 

1
2
3
4

LIST SCRIPT NAMES;                -- name of all local script
LIST GLOBAL SCRIPT NAMES;         -- name of all Global script
LIST ALL SCRIPT NAMES;            -- name of all script including 
                                  -- local and global

1
2
3
4
5
6
7
8
9
10
11
12
13

IF the script IS does NOT already EXISTS RMAN creates its.
 
REPLACE SCRIPT full_backup                      -- Replace local script
{ BACKUP DATABASE PLUS ARCHIVELOG; }
 
REPLACE GLOBAL SCRIPT global_full_backup -- Replace global script
 
COMMENT 'A script for full backup to be used with any database'
{ BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG; }
 
-- Replace with text file
REPLACE GLOBAL SCRIPT global_full_backup FROM FILE 'my_script_file.txt';  
 

1
2
3

DELETE SCRIPT 'full_backup';
DELETE GLOBAL SCRIPT 'global_full_backup';
 

9. Frequently Used Commands

10. Data Dictionary and Dynamic Performance Views

The Recovery Catalog view start with ( RC_*) for example

V$ARCHIVED_LOG  --Control file view

RC_ARCHIVED_LOG --Recovery catalog view

Related Articals:

1. Introduction to RMAN [Part-1]
2. Backup and recovery operations using RMAN (Part-2)
3. Using RMAN Repository (Part-3)