今天去逛一下書局，本想去找一下Oracle看有沒有值得買的書，買了兩本就開開心心的回家，回到家的時候我弟看到我買的書，念了我一下....
"你怎麼這麼不愛國，居然買大陸簡體書"

這時候我才發現，我所需要的知識補充，似乎未來只能在簡體中文去或者英文方面尋找了，在這塊土地上Oracle這方面的知識與技術超越我的人太多太多，但在我熟悉的文字中，似乎已經沒有願意分享寶貴的經驗與知識呈現，看來我所熟悉的文字在很多方面它的競爭力漸漸式微。

無彷~反正我意義上也是個外國奴，靠的外國人發明出來的軟體過生活，本來就沒資格要求在熟悉的語言下學習，也不能指責有分享的人"你寫的東西怎麼都是一筆帶過，誰看得懂"。

今天~來簡單的分享一下使用RMAN的備份檔達到異機還原的目的。

是否一定要Archive Log Mode???
No Archive Log
在這個模式底下，若要online的狀況下備份還原資料庫，只能使用export、import，但還原資料庫的時候就很頭大了，等於重建一個資料庫再把資料導入，必須要注意權限、Schema.....連import的順序也要考慮，若要做physical backup只能關閉資料庫做備份。

1 . 關閉資料庫、Listener
2 . 複製所有datafile、online redo logfile、control file、最好spfile也要。
3 . 開啟資料庫、Listener

Archive Log
在Archive Log模式底下，可以在online的實體備份(Physical Backup)，他會將資料庫目前的狀態備份下來，還原的時候既輕鬆多了，就像是把檔案放到該放的位置，設定一下資料庫就可以起來了。

RMAN(Recovery Manager)說明
在備份的時候，備份軟體總是要知道資料庫裡有甚麼檔案，時麼時候備份，備份了哪些內容，那些資料庫的檔案放在哪裡，這就是所謂RMAN的metadata。RMAN的可以建立一個Catalog Database來存放RMAN備份的資訊(不是備份資料)，若未設定RMAN Catalog Database，預設RMAN會將metadata存放於將備份Instance的Control File中。

RMAN的備份雖然可以不需要切換為begin backup 或end backup來達到各檔案的時間戳記一致，但資料庫必須要再Archive Log模式底下做備份。

Oracle Instance的結構
在備份前先討論一下Instance的組成結構與"時間點"曖昧的關係，Oracle Instance的組成零件如下。

1 . Datafile (存放ERP、人所衍生出的資料)
2 . online redo logfile (使用者所產生的資料變化與"進化"過程的過程把它記錄下來)
3 . control file (保持資料庫檔案的一致性，datafile路徑等，也包含RMAN的關鍵資料)
4 . server parameter file (pfile or spfile，資料庫的參數檔，)
5 . Password file (密碼檔，用於未啟動Instance時，管理者遠端登入用)

以上的幾個零件，Datafile、online redo logfile 、control file 有著曖昧不明的關西，當異常發生須要重新啟動資料庫的時候，資料庫會先將control file中的SCN與datafile、online redo logfile的SCN做比對，若時間點一致的話就不需要rollback，若不一致的話，就靠online redo logfile來做rollbackup，以此方式來滿足他們"時間點"曖昧，也保證了資料庫的資料一致性。

若online redo logfile無法滿足他們的愛眛呢，那就保佑你有開Archive Log了，不過這情況不大可能發生，預設online redo logfile有三個，Oracle內部的機制可以滿足絕大部分的rollback所需!!!

flash_recovery_area
Oracle 10g 新增的一項概念，他是一個資料夾，預設存放archive log、RMAN backup資料、control file的副本...等，但既然Oracle將他是命名為"Area"，但表這資料夾的容量受Oracle的限制，限制的參數為"db_recovery_file_dest_size"，預設是2G，滿的話資料庫異常。

RMAN備份與異機還原流程
1 . 來源資料庫 開啟Archive Log Mode，修正flash_recovery_area路徑與空間限制大小，預設的情況下RMAN的備份、Archive Log... 等都會存放在 flash_recovery_area，而 flash_recovery_area 又跟 datafile 放在同一個磁區中，如此一來備份會受到I/O競爭的影響，且習慣上 Archive Log 也不放在 flash_recovery_area。
2 . 來源資料庫 使用RMAN備份資料庫。
3 . 目的資料庫 還原時所需檔案的複製與資料庫環境的部屬。
      - 當還原的檔案都已經傳送到目的資料庫中，RMAN就必須要連到目的資料庫的Instance中做復原。
      - RAMN要有Instance可以連的話，目的資料庫的Instance至少開到nomount狀態下。
      - 資料庫 Instance要開到nomount狀態，就必須要有spfile、password file還要有Listener以及Instance所需的相關的資料夾。
4 . 目的資料庫 還原資料庫與開啟Instance。

初始化參數說明
control_file_record_keep_time
當RMAN未設定catalog database時，所有的RMAN備份紀錄都會存在control file中，預設control file
中保留RMAN備份紀錄為七天。

db_recovery_file_dest
Flash_recovery_area路徑，建議不要與datafile同一磁碟。

db_recovery_file_dest_size
Flash_recovery_area可使用空間的上限，預設為2G。

1 . 來源資料庫 開啟Archive Log Mode，修正flash_recovery_area路徑與空間限制大小。
建立所需目錄
# su - root
# mkdir -p /u03/archive_log/orcl
# mkdir -p /u03/flash_recovery_area
# chown oracle.oinstall -R /u03
# chmod -R 750 /u03/flash_recovery_area

修正資料庫參數
SQL> alter system set log_archive_dest_1="location=/u03/archive_log/orcl" scope=both;
SQL> alter system set db_recovery_file_dest='/u03/flash_recovery_area' scope=both;
SQL> alter system set db_recovery_file_dest_size=10G scope=both;

開啟Archive Log mode
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2 . 使用RMAN備份資料庫。
# su – oracle
$ rman target /
run {
configure controlfile autobackup on;
configure device type disk parallelism 2;
configure channel 1 device type disk connect='sys/manager@orcl';
configure channel 2 device type disk connect='sys/manager@orcl';
backup database plus archivelog;
}

3 . 在目的端主機上Listener部屬與還原時所需檔案的複製。

使用netca建立Listener與連線方式後，之後針對orcl的靜態註冊，並開啟Listener。
$ vi /u02/oracle/10g/network/admin/listener.ora
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u02/oracle/10g)
      (PROGRAM = extproc)
    )
      (SID_DESC =
      (SID_NAME = orcl)
      (ORACLE_HOME = /u02/oracle/10g)
    )
  )

$ su - oracle
$ lsnrctl start

建立Archive Log與flash_recovery_area目錄
# su - root
# mkdir -p /u03/archive_log/orcl
# mkdir -p /u03/flash_recovery_area/ORCL
# chmod -R 750 /u03/flash_recovery_area
# chown oracle.oinstall -R /u03/

建立orcl Instance所需目錄
# su - oracle
$ ORACLE_SID=orcl
$ OLD_UMASK=`umask`
$ umask 0027
$ mkdir -p /u02/oracle/10g/cfgtoollogs/dbca/orcl
$ mkdir -p /u02/oracle/10g/dbs
$ mkdir -p /u02/oradb/admin/orcl/adump
$ mkdir -p /u02/oradb/admin/orcl/bdump
$ mkdir -p /u02/oradb/admin/orcl/cdump
$ mkdir -p /u02/oradb/admin/orcl/dpdump
$ mkdir -p /u02/oradb/admin/orcl/pfile
$ mkdir -p /u02/oradb/admin/orcl/udump
$ mkdir -p /u02/oradb/oradata/orcl

在目的端上複製來源端資料庫的備份資料
$ su - oracle
$ cd /u02/oracle/10g/network/admin
$ scp -r oracle@來源端主機IP:/u02/oracle/10g/network/admin/tnsnames.ora .
$ cd /u02/oracle/10g/dbs
$ scp -r oracle@來源端主機IP:/u02/oracle/10g/dbs/spfileorcl.ora .
$ cd /u03/flash_recovery_area/ORCL
$ scp -r oracle@來源端主機IP:/u03/flash_recovery_area/ORCL/* .

4 . 還原資料庫與開啟Instance。

建立密碼檔與spfile。(可使用新建立或複製來源主機的檔案)
$ cd /u02/oracle/10g/dbs/
$ scp -r oracle@來源端主機:/u02/oracle/10g/dbs/orapworcl .
$ scp -r oracle@來源端主機:/u02/oracle/10g/dbs/spfileorcl.ora .

登入RMAN註冊DBID並將Instance開啟至nomount
$ su - oracle
$ rman target /
RMAN> set dbid=xxxxxxxx  #DBID在來源端主機使用RMAN即可得知，必須一樣。
RMAN> startup nomount;

復原control file，可在來源端主機使用rman下達list backup得知control file的備份檔案。
RMAN> restore controlfile from '/u03/flash_recovery_area/ORCL/autobackup/2012_04_23/o1_mf_s_781384123_7sbg1w12_.bkp';
       

RMAN> alter database mount;
RMAN> restore database; 

RMAN> recover database;
由於RMAN備份的過程中只會備份需要的ArchiveLog，但在備份時SCN某些部分已經是需要未來的Archive Log，所以直使用sql指令取消recover並開啟至open狀賴即可。

$ su – oracle
$ sqlplus ‘/as sysdba’
SQL> recover database using backup controlfile until cancel;
SQL> alter database open resetlogs; (會重新建立online redo file)

如以一來，移轉Database輕鬆多了。

6.4.1 Restoring the Control File from Backup

Loss or corruption of all copies of your control file requires restore of the control file from backup. The RESTORE CONTROLFILE command is used to restore the control file.

RMAN can restore the control file to its default location (determined by rules described in the following section) or to one or more different locations of your choice, using the RESTORE CONTROLFILE... TO destination option.

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

RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;

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

RMAN> RESTORE CONTROLFILE from 'filename';

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

6.4.2 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 (for example, ? /dbs/spfile.ora on Linux).

• 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.

RMAN can also create a client-side initialization parameter file based on a backup of an SPFILE.

To restore the server parameter file:

1. If the database is up at the time of the loss of the SPFILE, connect to the target database. For example, run:

   
   

   
   % 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. See "Determining your DBID" for details on determining your DBID.

2. 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:

   
   

   
   RMAN> STARTUP FORCE NOMOUNT;
   

   
   

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

   
   

   
   RMAN> RESTORE SPFILE FROM AUTOBACKUP;
   

   
   

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

   
   

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

   
   

4. 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:

   
   

   
   SPFILE=/tmp/spfileTEMP.ora
   

   
   

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

   
   

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

   
   

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

RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';

RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora';

6.4.3 Restoring and Recovering Datafiles and Tablespaces

Restoring a tablespace to its original location and performing media recovery on it is described in "Restore and Complete Recovery of Individual Tablespaces or Datafiles: Scenario". However, you may need to restore a datafile to a location other than its original location if, for example, the disk containing the original location of the datafiles has failed.

RUN
{
  SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
  SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE';
  # specify the new location for each datafile
  SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO
                           '/newdisk/users01.dbf';
  SET NEWNAME FOR DATAFILE '/olddisk/tools01.dbf' TO
                           '/newdisk/tools01.dbf';
  # to restore to an ASM disk group named dgroup, use:
  # SET NEWNAME FOR DATAFILE '/olddisk/trgt/tools01.dbf'
  #     TO '+dgroup';
  RESTORE TABLESPACE users, tools;
  SWITCH DATAFILE ALL;   # update control file with new filenames
  RECOVER TABLESPACE users, tools;
}

SQL 'ALTER TABLESPACE users ONLINE';
SQL 'ALTER TABLESPACE tools ONLINE';

RMAN> RECOVER DATABASE;

RMAN> RECOVER DATABASE SKIP TABLESPACE users;
RMAN> RECOVER TABLESPACE users, tools;
RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf';
RMAN> RECOVER DATAFILE 4;

RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG;

RUN {
    SET NEWNAME FOR DATAFILE 3 to 'new_location';
    RESTORE DATAFILE 3;
    SWITCH DATAFILE 3;
    RECOVER DATAFILE 3;
}

RUN {
    SET NEWNAME FOR DATAFILE 3 to NEW;
    RESTORE DATAFILE 3;
    SWITCH DATAFILE 3;
    RECOVER DATAFILE 3;
}

6.4.4 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. These parameters are combined in a platform-specific fashion to form the name of the restored archived log.

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
  .
  .
  .
}

Restore and Recovery of NOARCHIVELOG Databases

Restore of a database running in NOARCHIVELOG mode is very similar to restore of a database in ARCHIVELOG mode. The main differences are:

• 
  

  Only cold backups (that is, backups created when the database was shut down normally) can be used in restoring a database in NOARCHIVELOG mode

• Media recovery is not possible, because there are no archived logs

A limited form of restore and recovery is possible for NOARCHIVELOG databases if the backup strategy for the database includes incremental backups. The incremental backups (which, like the full backup of a NOARCHIVELOG database must be created when the database is shut down) can be applied to a full database backup to apply recent changes up to the time of the incremental backup.

STARTUP FORCE MOUNT;
RESTORE CONTROLFILE;  # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE;  # restore datafiles from consistent backup
RECOVER DATABASE NOREDO;  # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;

Restore and Recovery of the Database on a New Host

The procedure described in this section can be used to perform test restores, or to move a production database to a new host.

Performing Recovery with a Backup Control File

If all copies of the current control file are lost or damaged, then you must restore and mount a backup control file before you can perform recovery. When using a backup control file, and using a recovery catalog, the process is identical to recovery with a current control file, as the RMAN repository information missing from the backup control file is available from the recovery catalog. There are special considerations when using a backup controlfile and not using a recovery catalog.

The following notes and restrictions apply regardless of whether you use a recovery catalog:

• You must run the RECOVER command after restoring a backup control file, even if no datafiles have been restored.

• You must open the database with the RESETLOGS option after performing either complete or point-in-time recovery with a backup control file.

• If the online redo logs are inaccessible, then you must perform incomplete recovery to an SCN before the earliest SCN in the online redo logs. This limitation is necessary because RMAN does not back up online logs.

• During recovery, RMAN automatically searches for online and archived redo logs that are not recorded in the RMAN repository, and catalogs any that it finds so that it can use them in recovery.

  
  

  RMAN attempts to find a valid archived log in any of the current archiving destinations with the current log format. The current format is specified in the initialization parameter file used to start the instance (or all instances in a Real Application Clusters installation). Similarly, RMAN attempts to find the online redo logs by using the filenames as specified in the control file.

  If you changed the archiving destination or format during recovery, or if you added new online log members after the backup of the control file, then RMAN may not be able to automatically catalog a needed online or archived log. In this situation, RMAN reports errors similar to the following:

  
  

  
  RMAN-00571: ===========================================================
  RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
  RMAN-00571: ===========================================================
  RMAN-03002: failure of recover command at 08/29/2001 14:23:09
  RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945
  

  
  

  In this case, you must use the CATALOG command to manually add the required logs to the repository so that recovery can proceed. The cataloging procedure is described in Oracle Database Backup and Recovery Basics.

Performing Disaster Recovery

Disaster recovery includes the restore of and recovery of the target database after the loss of the entire target database, the recovery catalog database, all current control files, all online redo log files, and all parameter files.

To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.

The basic procedure for disaster recovery begins with restoring an autobackup of the server parameter file, as described in Oracle Database Backup and Recovery Basics.

Once you have an SPFILE, you can start the target database instance, restore the control file from autobackup and mount it.

With the control file mounted, then follow the instructions found in
"Performing Recovery with a Backup Control File" to restore and recover your datafiles.

The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:

• You are restoring the database to a new host with the same directory structure.

• You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.

• You do not use a recovery catalog.

In this scenario, perform the following steps:

# Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT;  # rman starts instance with dummy parameter file
RUN
{
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
  # Manually allocate a channel to the media manager
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  # Restore autobackup of the control file. This example assumes that you have
  # accepted the default format for the autobackup name.
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  #  The set until command is used in case the database
  #  structure has changed in the most recent backups, and you wish to
  #  recover to that point-in-time. In this way RMAN restores the database
  #  to the same structure that the database had at the specified time.
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 1124 THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery completes

The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:

RMAN> RUN
{
  #  If you need to restore the files to new locations, tell Recovery Manager
  #  to do this using SET NEWNAME commands:
  SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
  SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
  SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 124 THREAD 1;
  RESTORE DATABASE;
  SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;

Performing Block Media Recovery with RMAN

The BLOCKRECOVER command can restore and recover individual datablocks within a datafile. This procedure is useful when a trace file or standard output reveals that a small number of blocks within a datafile are corrupt.

Block media recovery is not useful in cases where the extent of data loss or corruption is not known; in this case, use datafile recovery instead.

RMAN Restore and Recovery Examples

The following sections illustrate the use of RMAN restore and recovery techniques in advanced scenarios.

SET DBID = target_dbid;

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;

RESTORE DATABASE;
RECOVER DATABASE
  # optionally, delete logs restored for recovery and limit disk space used
  DELETE ARCHIVELOG MAXSIZE 2M;

# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE history;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";

Even if you are not an Oracle DBA, you’ll still encounter a situation where you may have to take a backup of an Oracle database.

Using Oracle RMAN, you can take a hot backup for your database, which will take a consistent backup even when your DB is up and running.

This tutorial gives you an introduction on how to perform Oracle DB backup using RMAN.

For the impatient, here is the quick snippet, that takes RMAN backup of both database and archive logs.

RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

1. View Current RMAN Configuration

Before we take the backup, we have to configure certain RMAN parameters. For example, how long you want to reatain the RMAN backup, etc.

Before we modify any configuration, execute the following command to view all current RMAN configuration settings.

To connect to RMAN, do the following from command line. This will take you to RMAN> command prompt, from here you can execute all RMAN commands.

$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Sat Aug 10 11:21:29 2013
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database: DEVDB (DBID=821773)
RMAN>

To view current RMAN configurations, execute “show all”.

RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO "/backup/rman/ctl_%F";
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   "/backup/rman/full_%u_%s_%p" MAXPIECESIZE 2048 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2.0/dbs/snapcf_devdb.f'; # default

As you see above, it displays various RMAN parameters and their current values.

2. Change Few RMAN Configuration Parameters

Location: One of the important configuration parameters to set will be, where you want to save the RMAN backup. In the following example, I’m settting the RMAN backup loacation as “/backup/rman/”

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/rman/full_%u_%s_%p';

Retention Period: Next, you should specify how long you want to retain the backup for. When RMAN takes a backup, it automatically deletes all the old backups that are older than the retention period. In the following example, I’m setting the retention period as 7 days, which will keep the DB backup for a week.

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

Verify that the above two changes are done.

RMAN> SHOW ALL;
..
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/backup/rman/full_%u_%s_%p';
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
..

Clear a Parameter: If you want to clear a parameter and set its value to default, use CLEAR at the end of the configuration as shown below.

RMAN> CONFIGURE RETENTION POLICY CLEAR;

In this example, since we cleared the retention policy’s value, it was set to the default value, which is 1. So, the retention policy is set to 1 day as shown below.

RMAN> SHOW ALL;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

3. Backup Oracle Database

Make sure the directory mentioned in the CHANNEK DEVICE TYPE DISK FORMAT is created. i.e /backup/rman/

$ mkdir -p /backup/rman

Currently this directory is empty. We’ll see what this has after the backup is taken.

$ ls -l /backup/rman
total 0

We can take a backup using image copy or in backup set. It is strongly recommended to use RMAN backup sets to backup the database.

RMAN stores the backup in backup sets, which are nothing but whole bunch of files which contains the backed-up data. Only RMAN understands the format of these files. So, if you backup an Oracle DB using RMAN, only RMAN knows how to read the backup and restore it.

Typically we’ll use “BACKUP AS BACKUPSET” to backup a database. So, to take a full backup of the database without the archive logs, do the following.

RMAN> BACKUP AS BACKUPSET DATABASE

To take a full backup of the database with the archive logs, do the following:

RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

You can also take a backup of only a specific table space. The following example takes backup of only PRD01 tablespace.

RMAN> BACKUP AS BACKUPSET TABLESPACE PRD01;

The RMAN backup output will be something similar to the following:

RMAN> BACKUP AS BACKUPSET DATABASE
Starting backup at 10-AUG-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=193 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=192 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00025 name=/u03/oradata/devdb/devuser07.dbf
input datafile fno=00003 name=/u02/oradata/devdb/temp01.dbf
channel ORA_DISK_1: starting piece 1 at 10-AUG-13
channel ORA_DISK_2: starting full datafile backupset
channel ORA_DISK_2: specifying datafile(s) in backupset
input datafile fno=00008 name=/u03/oradata/devdb/devusers05.dbf
channel ORA_DISK_2: starting piece 1 at 10-AUG-13
...
..
piece handle=/backup/rman/full_4dogpd0u_4237_1 tag=TAG20130808T114846 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 10-AUG-13
...
Starting Control File and SPFILE Autobackup at 10-AUG-13
piece handle=/backup/rman/ctl_c-758818131-20130808-00 comment=NONE
Finished Control File and SPFILE Autobackup at 10-AUG-13

Once the backup is completed, do an ls on the /backup/rman directory, you’ll now see RMAN backup files.

$ ls -l /backup/rman
total 14588
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1

Note: Once a backup is taken, to view all available database backups from RMAN, you need to use “list” command that is shown further down in one of the examples.

While this may be obvious, it is worth repeating again: Since we are taking hotbackup, the Oracle database can be up and running. Make sure your Oracle database is running before you execute any of the above RMAN backup commands.

4. Assign Backup TAG Name for Quick Identification

If you are taking lot of backups, it will be easier to assign a tag to a particular backup, which we’ll later use during Oracle recovery (or while using list command to view it).

The following example assign a backup tag called “WEEEKLY_PRD01_TBLS_BK_ONLY” to this particular backup.

RMAN> BACKUP AS BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;
Starting backup at 10-AUG-13
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00002 name=/u03/oradata/devdb/PRD01_1.dbf
channel ORA_DISK_1: starting piece 1 at 10-AUG-13
channel ORA_DISK_1: finished piece 1 at 10-AUG-13
piece handle=/backup/rman/full_4fogpdb3_4239_1 tag=WEEEKLY_PRD01_TBLS_BK_ONLY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 10-AUG-13
Starting Control File and SPFILE Autobackup at 10-AUG-13
piece handle=/backup/rman/ctl_c-758818131-20130808-01 comment=NONE
Finished Control File and SPFILE Autobackup at 10-AUG-13

Once the backup is finished, if you view the files from rman directory, you’ll not see the tag name here. Tag name is used only from RMAN repositories to view and restore backups. So, now you see there are more files in this directory, as we’ve taken couple of backups.

$ ls -l /backup/rman/
total 29176
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1

5. Change Oracle RMAN Backup File Name Format

If you want the backup files itself will be in a specific format, you need to change the format in the RMAN configuration as shown below. In this example, we’ve appended the tag “full_devdb_bk_” prefix to all our backup files.

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   "/backup/rman/full_devdb_bk_%u_%s_%p" MAXPIECESIZE 2048 M;

Now, let us take another backup with this modified configuration.

RMAN> BACKUP AS BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;

Now when you view the RMAN files, you’ll see the new RMAN backup file has this new file name format for the files. This is easier to identify certain information about the backup just by looking at the file names.

$ ls -l /backup/rman/
total 43764
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba 14585856 Aug  8 11:56 ctl_c-758818131-20130808-02
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:55 full_devdb_bk_4hogpdef_4241_1

6. Compress a RMAN Backup

If you are taking a backup of a big database, you’ll notice that the RMAN backup files are bigger (almost same size as the database itself).

So, for most situation, you should always tak ea compressed backup of the database.

The following example take a compressed backup of the tablepsace PRD01.

RMAN> BACKUP AS COMPRESSED BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;

When you view the backup files from the file system level, you will not see any .gz (or .zip, or .bz2) to indicate that the RMAN has taken a compressed backup. The file naming convention will still follow the same as a non-compressed backup.

$ ls -l /backup/rman/
total 58352
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba 14585856 Aug  8 11:56 ctl_c-758818131-20130808-02
-rw-r----- 1 oracle dba 14585856 Aug  8 11:59 ctl_c-758818131-20130808-03
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:55 full_devdb_bk_4hogpdef_4241_1
-rw-r----- 1 oracle dba   127680 Aug  8 11:59 full_devdb_bk_4jogpdl0_4243_1

Note: The way to tell whether RMAN has take a compressed backup or not, it by looking at the size, and by looking at the output of the RMAN “list” command which is shown in one of the section below.

7. View all RMAN Backups

To view all the RMAN backups, execute “list backup summary” as shown below.

RMAN> LIST BACKUP SUMMARY;
using target database control file instead of recovery catalog
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
..
4215    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T114846
4216    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T114849
4217    B  F  A DISK        10-AUG-13       1       1       NO         WEEEKLY_PRD01_TBLS_BK_ONLY
4218    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T115413
4219    B  F  A DISK        10-AUG-13       1       1       NO         WEEEKLY_PRD01_TBLS_BK_ONLY
4220    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T115600
4221    B  F  A DISK        10-AUG-13       1       1       YES        WEEEKLY_PRD01_TBLS_BK_ONLY

As you see above, it displays various information about the backups. In the above output, it show 7 RMAN backups. The last column shows the “Tag” that we specified when we took a backup. If we didn’t specify any TAG, RMAN creates a default tag with the prefix “TAG” followed by some numbers. You can also see that under the column “Compressed”, the last RMAN backup shows “YES”, which indicates that out of all the 7 RMAN backups, only the last one was compressed.

Also, when the RMAN backup is running, if you want to see the proress, you can query the V$RMAN_STATUS table from sql*plus as shown below.

SQL> SELECT OPERATION, STATUS, MBYTES_PROCESSED, START_TIME, END_TIME from V$RMAN_STATUS;
OPERATION                         STATUS                  MBYTES_PROCESSED START_TIM END_TIME
--------------------------------- ----------------------- ---------------- --------- ---------
CONTROL FILE AND SPFILE AUTOBACK  COMPLETED                             14 07-NOV-12 07-NOV-12
RMAN                              COMPLETED                              0 07-NOV-12 07-NOV-12
RESTORE VALIDATE                  COMPLETED                              0 07-NOV-12 07-NOV-12
RMAN                              COMPLETED WITH ERRORS                  0 07-NOV-12 07-NOV-12
DELETE                            COMPLETED                              0 08-NOV-12 08-NOV-12
BACKUP                            COMPLETED                              0 10-AUG-13 10-AUG-13
CONTROL FILE AND SPFILE AUTOBACK  COMPLETED                             14 10-AUG-13 10-AUG-13
RMAN                              COMPLETED WITH ERRORS               1832 10-AUG-13 10-AUG-13
RMAN                              COMPLETED                              0 10-AUG-13 10-AUG-13
...

There you have it!. That is how you take an Oracle RMAN backup and sleep peacefully.

As a Linux sysadmin, you might recover a system from backup, which may include Oracle Database.

So, it is essential for all admins to understand how to restore oracle database from backup.

Typically, DBAs will use Oracle RMAN utility to take a hot backup of the database.

This tutorial provides an introduction on how to restore an Oracle database from the RMAN backup.

If you are new to RMAN, you should first understand how to backup oracle database using RMAN.

For the impatient, here is a quick snippet of one particular rman restore scenario. Change this accordingly for your scenario. Read below to understand more details about these commands.

RMAN> SET DBID 12345;
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03";
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

Verify Backup Location

Before the restore, verify the current RMAN configuration on the server where you’ll be performing the restore.

To connect to RMAN, execute the following rman command, which will take you to the RMAN> prompt. From here, you can execute all RMAN commands.

$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Mon Nov 17 11:17:11 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: DEVDB (DBID=821773)
RMAN>

Execute “show all”, which will display all current RMAN configuration. As you see below, the current RMAN backup is located under “/backup/rman” directory.

RMNAN> SHOW ALL;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/rman/ctl_%F';
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/data/rman-backup/full_%u_%s_%p' MAXPIECESIZE 4096 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/backup/rman/snapcf_med.f';

On a high-level, the following three steps are performed in recovering the database from RMAN backup.

1. Restore controlfile from backup
2. Restore the databse
3. Recover the database

WARNING: Execute rman restore commands only on a test instance. If you try these restore commands in a production instance, and if something goes wrong, you’ll lose your production data.

Step 1: Restore ControlFile from Backup

First, you may want to restore the control file from the backup before you start the restore.

This step is required only if you are restoring the backup on a new server where the control file doesn’t exist. Or, if the control file on the system you are restoring is corrupted or missing.

RMAN> SET DBID 12345;
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03";
RMAN> ALTER DATABASE MOUNT;

Before you start the RMAN restore process, do the following:

• Set the DBID. You can get the dbid from the name of the control file. This is the number that comes after “ctrl_c-” and the next hyphen. Please note that this depends on the controlfile format that was set on your system. Do a show all to view the format. For this example, the format was: “ctl_%F”
• Startup the database in nomount option
• Restore the controlfile form the backup. In this example, the RMAN backup is located under /backup/rman directory. Under this directory, you may have multiple control files. Based on the tiemstamp pick the appropriate one for which you have the full backup.
• After restoring the control file, mount the database.

The following is an example output of the restore controlfile command:

Starting restore at 22-NOV-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=124 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/u01/oradata/devdb/control01.ctl
output filename=/u02/oradata/devdb/control02.ctl
output filename=/u03/oradata/devdb/control03.ctl
Finished restore at 22-NOV-14

When the RMAN backup was taken, if a tag was specified, you can also restore controlfile based a tag name as shown below.

RMNAN> RESTORE CONTROLFILE FROM TAG 'WEEKLY_FULL_BKUP';

You can also use the autobackup option to restore the controlfile as shown below:

RMNAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

Step 2: Restore the Database

To restore from the RMAN full backup that is located under the /backup/rman directory, execute the following command.

RMAN> RESTORE DATABASE;

Apart from the above straight forward restore database, there are also few variations of this command which are explained in the examples below. Use the one that is appropriate for your situation.

The following is a sample output of the above restore database command:

RMAN>
Starting restore at 22-NOV-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=125 devtype=DISK
...
channel ORA_DISK_2: starting datafile backupset restore
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
restoring datafile 00020 to /u01/oradata/devdb/dev01_1.dbf
restoring datafile 00021 to /u02/oradata/devdb/report_data.dbf
restoring datafile 00022 to /u01/oradata/devdb/analytics01.dbf
channel ORA_DISK_2: reading from backup piece /backup/rman/full_32qakgmpa_123456_1
channel ORA_DISK_4: starting datafile backupset restore
....

Step 3: Recover Database (and ResetLogs)

If you’ve restored the controlfile from the backup, you need to perform this step.

In the last step, recover the database, and then you should open the database with resetlogs options as show below:

RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

Restore Specific Tablespace

Instead of restoring the full database, you can also restore only specific tablespace as shown below.

The following will restore only the dev1 tablespace

RMNAN> RESTORE TABLESPACE dev1;

You can also restore more than one tablespace by separating them with commas as shown below. This will restore both dev1 and dev2 tablespace.

RMNAN> RESTORE TABLESPACE dev1, dev2;

Restore Specific Datafiles

You can also restore only a specific datafile from the backup using the restore datafile command as shown below.

The following will restore only the dev1_01.dbf datafile.

RMNAN> RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf'

You can also restore more than one datafile by separating them with commas as shown below. This will restore both dev1_01 and dev1_02 datafiles

RMNAN> RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf', '/u01/oradata/devdb/dev1_02.dbf'

Instead of the datafile name, you can also specify the datafile number.

RMNAN> RESTORE DATAFILE 34, 35

The datafile number (file_id) can be found in the dba_data_files table:

SQL> select file_id, file_name from dba_data_files
   FILE_ID FILE_NAME
---------- -------------------------------
        34 /u01/oradata/devdb/dev1_01.dbf
        35 /u01/oradata/devdb/dev1_02.dbf

Restore the Archived Redo Logs

The following will restore the archive logs to the default location.

RMNAN> RESTORE ARCHIVELOG ALL;

If you want to restore the archive logs to a new directory, do the following:

RMNAN> SET ARCHIVELOG DESTINATION TO '/home/arc_logs_new/';
RMNAN> RESTORE ARCHIVELOG ALL;

The following will restore only specific sequence number of the archive logs that are between 153 and 175.

RMNAN> RESTORE ARCHIVELOG FROM SEQUENCE 153 UNTIL SEQUENCE 175;

You can also restore archivelogs by specifying the starting point of the SCN number as shown below.

RMNAN> RESTORE ARCHIVELOG FROM SCN 56789;

Please note that when you issue the recover database as mentioned in the step 3 above, it will look for all required archive logs from the archive log destination and applies them to the oracle database datafiles.

Recover Specific Tablespace or Datafile

Similar to restoring specific tablespace and datafile, depending on the restore operation you did, perform the corresponding recover option. The following are few examples:

RMAN> RECOVER TABLESPACE dev1;
RMAN> RECOVER TABLESPACE dev1, dev2;
RMAN> RECOVER DATAFILE '/u01/oradata/devdb/dev1_01.dbf'
RMAN> RECOVER DATAFILE 34, 35

Note: You can also append “DELETE ARCHIVELOG” option to the recover command, which will delete the restored archive logs from the disk which are not required anymore. For example:

RMNAN> RECOVER TABLESPACE dev1 DELETE ARCHIVELOG;

Preview the Restore

Before restoring the database, if you like to view the details of all the backupsets that will be used along with the SCNs that are part of the backup file, you can append “PREVIEW” to any of the restore databse command. Please note that the preview output will be similar to the rman list summary command output.

This really doesn’t do the restore. This will only provide the report. You can use this before you restore the database.

RMAN> RESTORE DATABASE PREVIEW;

Pelase note that if the output of the above PREVIEW command is too detailed, and you need only the summary, you can execute the following PREVIEW SUMMARY.

RMAN> RESTORE DATABASE PREVIEW SUMMARY;

The following is the sample output of the above preview summary:

Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
234587  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234588  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234589  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234580  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
234581  B  F  A DISK        22-NOV-14       1       1       YES        WEEKLY_FULL_BKUP
..

The following are also valid preview option. You can append SUMMARY to all of the following commands:

RESTORE TABLESPACE dev1 PREVIEW;
RESTORE DATAFILE '/u01/oradata/devdb/dev1_01.dbf' PREVIEW;
RESTORE ARCHIVELOG ALL PREVIEW;
RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW;

Validate the Backup Before Restore (Dry-run)

Before you perform the restore, you might want to really validate the backup to make sure that the backup itself is not corrupted, and all the file required to perform the backup is actually present in the backup directory.

RMAN> RESTORE DATABASE VALIDATE;

Depending on the size of the database this operation might take some time to complete. Technically, this is same as restoring the database except that this doesn’t do the real restore, and it performs only the Dry-run. The validate operation will really read all the blocks in the RMAN backup to make sure they are valid.

The following is a sample output of the restore validate command:

Starting restore at 22-NOV-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=123 devtype=DISK
...
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_2: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /backup/rman/full_3abcde4po_123456_1
channel ORA_DISK_2: reading from backup piece /backup/rman/full_32qakgmpa_123456_1
channel ORA_DISK_1: restored backup piece 1
...
channel ORA_DISK_2: validation complete, elapsed time: 00:53:11
Finished restore at 22-NOV-14

RMAN Restore Common Error Messages

The following are some of the most common RMAN restore error messages:

Error 1: Start-up mount might give the following RMAN-04014 error:

RMAN> STARTUP NOMOUNT
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 10/03/2014 11:04:19
RMAN-04014: startup failed: ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 9925

Solution 1: Create the audit trial directory. Change the path to match your system.

mkdir -p $ORACLE_BASE/admin/devdb/adump

Error 2: Restore controlfile might give the following RMAN-00558, RMAN-01006, or RMAN-02001 error.

RMAN> RESTORE CONTROLFILE FROM /backup/rman/ctl_c-12345-20141003-03
RMAN-00558: error encountered while parsing input commands
RMAN-01006: error signaled during parse
RMAN-02001: unrecognized punctuation symbol "/"

Solution 2: Make sure to include the whole controlfile patch within quotes as shown below.

RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03";

Error 3: Restore controlfile (or restore database) might give the following RMAN-03002, ORA-19870, or ORA-27040 error along with “Linux-x86_64 Error: 2: No such file or directory”.

RMAN> RESTORE CONTROLFILE FROM "/backup/rman/ctl_c-12345-20141003-03";
RMAN-03002: failure of restore command at 10/03/2014 11:12:25
ORA-19870: error while restoring backup piece /backup/rman/ctl_c-12345-20141003-03
ORA-19504: failed to create file "/u01/oradata/devdb/control01.ctl"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory

Solution 3: In most cases it is missing directory. Create the appropriate directories accordingly. You might also get not found messsage for flash_recovery_area directory. So, create them both. Or, create whatever directory the above error message is complaining about.

mkdir -p $ORACLE_BASE/oradata/devdb
mkdir -p $ORACLE_BASE/flash_recovery_area/devdb/

Error 4: When you alter database open resetlogs, you might get the following ORA-01152 error message:

RMAN> ALTER DATABASE OPEN RESETLOGS;
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/oradata/devdb/system01.dbf'

Solution 4: You can try couple of things. First, try to recover database until cancel as shown below. If that doesn’t help, remove the “UNTIL CANCEL” from the following command, and specify the redo log file, when it asks for “Specify log:” during the recover database command:

RMAN> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;