An introduction to rman with examples.

For beginners and non, rman is one of the most obscure Oracle tools, but in reality it is based on quite
simple principles. It is true, though, that a restoration can be distructive for a database.

Why is rman dangerous?

rman is dangerous because it works at the database physical level; to understand why, let's say that rman
is not "too" different from WinZip. Since everybody knows WinZip, it will probably be easier to
understand rman.

Is WinZip dangerous?
The creation of a zip archive is not dangerous, unless you choose the same name for the output file, or the
archive is so big that you fill a device or the temporary directory etc. The same thing can be said about
rman: taking an rman backup cannot be dangerous (unless you stop the database, or close it intentionally)
and you don't overwrite previous backups (you can prevent it).
rman creates a compressed backup of the physical database files, including controlfiles, datafiles,
archived logs and stores them somewhere. This somewhere can be a disk (like WinZip) or a tape.
Therefore, the first important point to remember is:

rman creates compressed backups of the physical database; if you prefer, rman zips the database,
entirely or not.

Is Unzip dangerous?
Unzip, on the other hand, can be very dangerous. The risk is overwriting files that should not be
overwritten and, therefore, losing important content. The very same applies to rman restores: since they
overwrite database files, you should know whether this is the right decision because, otherwise, you may
lose your data. This is the main difference between an import and an rman restoration: an rman
restoration (restore) overwrites one or more datafiles; this means WATCH OUT.

Our first rman backup

The only requirements for taking simple, useful rman backups are two:

• You database is in archivelog mode

• You have enough disk space somewhere

On our Windows 2000 workstation we open a CMD window and type the following few lines:
E:\>rman target /

Recovery Manager: Release 9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: ARK9201 (DBID=3564144589)

run {
allocate channel t1 type disk;
backup database format 'E:\RMAN_BACKUPS\ARK9201\%d_%u_%s';
release channel t1;
}
using target database controlfile instead of recovery catalog
allocated channel: t1
channel t1: sid=9 devtype=DISK

Starting backup at 10-DEC-04

channel t1: starting full datafile backupset
channel t1: specifying datafile(s) in backupset
including current SPFILE in backupset
including current controlfile in backupset
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t1 channel at 12/10/2004 14:28:50
ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode
As we said, the database must be in archive mode if we want to backup open databases. A separate
articles explains why it must be so, because it is not so obvious.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 135338868 bytes

Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> alter database archivelog;

Database altered.
SQL> alter database open;

Database altered.
Let's now repeat the operation having put the database in archive mode Choosing C:\Temp as directory
for the backup is, of course, a very bad idea. Backups are gold and shoud be kept on a dedicated device; a
good name could be E:\RMAN_BACKUPS\SID
E:\>rman target /

Recovery Manager: Release 9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: ARK9201 (DBID=3564144589)

RMAN> run {
2> allocate channel t1 type disk;
3> backup database format 'E:\RMAN_BACKUPS\ARK9201\%d_%u_%s';
4> release channel t1;
5> }

allocated channel: t1
channel t1: sid=12 devtype=DISK

Starting backup at 26-DEC-04

channel t1: starting full datafile backupset
channel t1: specifying datafile(s) in backupset
including current SPFILE in backupset
including current controlfile in backupset
input datafile fno=00001 name=E:\ORACLE\ORADATA\ARK920\SYSTEM01.DBF
input datafile fno=00002 name=E:\ORACLE\ORADATA\ARK920\UNDOTBS01.DBF
input datafile fno=00004 name=E:\ORACLE\ORADATA\ARK920\EXAMPLE01.DBF
input datafile fno=00009 name=E:\ORACLE\ORADATA\ARK920\XDB01.DBF
input datafile fno=00005 name=E:\ORACLE\ORADATA\ARK920\INDX01.DBF
input datafile fno=00008 name=E:\ORACLE\ORADATA\ARK920\USERS01.DBF
input datafile fno=00003 name=E:\ORACLE\ORADATA\ARK920\DRSYS01.DBF
input datafile fno=00006 name=E:\ORACLE\ORADATA\ARK920\ODM01.DBF
input datafile fno=00007 name=E:\ORACLE\ORADATA\ARK920\TOOLS01.DBF
channel t1: starting piece 1 at 26-DEC-04
channel t1: finished piece 1 at 26-DEC-04
piece handle=E:\RMAN_BACKUPS\ARK9201\ARK920_03G8KC6G_3 comment=NONE
channel t1: backup set complete, elapsed time: 00:25:58
Finished backup at 26-DEC-04

released channel: t1
The resulting backup file(s) are in our case
dir c:\rman_backups\ark9201
Volume in drive C is 80-01-14A2
Volume Serial Number is 64DA-0BF7

Directory of c:\rman_backups\ark9201

12/26/2004 02:29p .
12/26/2004 02:29p ..
12/26/2004 02:44p 418,471,936 ARK920_03G8KC6G_3

Our first archive backup

Taking only the database backup is not enough, for reasons that will be clear later. We must take a
backup of the archived log as well, and the command is very similar
RMAN> run {
2> allocate channel t1 type disk;
3> backup archivelog all delete input format 'C:\RMAN_BACKUPS\ARK9201\arch_%d_%u_
%s';
4> release channel t1;
5> }

allocated channel: t1
channel t1: sid=12 devtype=DISK
Starting backup at 26-DEC-04
current log archived
channel t1: starting archive log backupset
channel t1: specifying archive log(s) in backup set
input archive log thread=1 sequence=77 recid=1 stamp=545945036
input archive log thread=1 sequence=78 recid=2 stamp=545945039
input archive log thread=1 sequence=79 recid=3 stamp=545945099
channel t1: starting piece 1 at 26-DEC-04
channel t1: finished piece 1 at 26-DEC-04
piece handle=C:\RMAN_BACKUPS\ARK9201\ARCH_ARK920_04G8KTGL_4 comment=NONE
channel t1: backup set complete, elapsed time: 00:00:37
channel t1: deleting archive log(s)
archive log filename=E:\ORA920\RDBMS\ARC00077.001 recid=1 stamp=545945036
archive log filename=E:\ORA920\RDBMS\ARC00078.001 recid=2 stamp=545945039
archive log filename=E:\ORA920\RDBMS\ARC00079.001 recid=3 stamp=545945099
Finished backup at 26-DEC-04

released channel: t1

RMAN>

rman on UNIX
rman works the same way on a UNIX server, using an appropriate directory format:
RMAN> run { allocate channel t1 type disk;
2> backup database format '/u01/oracle/archive/%d_%u_%s';
3> backup current controlfile format '/u01/oracle/archive/%d_%u_%s';
4> release channel t1;}

using target database controlfile instead of recovery catalog

allocated channel: t1
channel t1: sid=26 devtype=DISK

Starting backup at 14:29:22 18-jan-2005

channel t1: starting full datafile backupset
channel t1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/oradata/ORA920/system01.dbf
input datafile fno=00002 name=/u02/oradata/ORA920/undo01.dbf
input datafile fno=00004
name=/u01/oradata/OMF_DATA_ORA920/o1_mf_tbs_data_0ybcd28z_.dbf
input datafile fno=00003 name=/u01/oradata/OMF_DATA_ORA920/o1_mf_tools_0ybbwkp7_.dbf
input datafile fno=00005 name=/u01/oradata/ORA920/oem_repository.dbf
channel t1: starting piece 1 at 14:29:24 18-jan-2005
channel t1: finished piece 1 at 14:31:10 18-jan-2005
piece handle=/u01/oracle/archive/ORA920_01gah0q3_1 comment=NONE
channel t1: backup set complete, elapsed time: 00:01:48
Finished backup at 14:31:11 18-jan-2005

Starting backup at 14:31:11 18-jan-2005

channel t1: starting full datafile backupset
channel t1: specifying datafile(s) in backupset
including current controlfile in backupset
channel t1: starting piece 1 at 14:31:15 18-jan-2005
channel t1: finished piece 1 at 14:31:18 18-jan-2005
piece handle=/u01/oracle/archive/ORA920_02gah0th_2 comment=NONE
channel t1: backup set complete, elapsed time: 00:00:05
Finished backup at 14:31:18 18-jan-2005

Starting Control File Autobackup at 14:31:18 18-jan-2005

piece handle=/optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-00 comment=NONE
Finished Control File Autobackup at 14:31:22 18-jan-2005

released channel: t1

RMAN> host ;

oracle@edc-se[on pts/4] ls -ltr /u01/oracle/archive/

total 562128
-rw-r----- 1 oracle dba 282476544 Jan 18 14:31 ORA920_01gah0q3_1
-rw-r----- 1 oracle dba 5177344 Jan 18 14:31 ORA920_02gah0th_2
oracle@edc-se[on pts/4] exit
host command complete

Backup the controlfile

RMAN> run { allocate channel t1 type disk;
2> backup current controlfile format '/u01/oracle/archive/controlf_%d_%u_%s';
3> release channel t1;}

allocated channel: t1
channel t1: sid=26 devtype=DISK

Starting backup at 14:33:59 18-jan-2005

channel t1: starting full datafile backupset
channel t1: specifying datafile(s) in backupset
including current controlfile in backupset
channel t1: starting piece 1 at 14:34:00 18-jan-2005
channel t1: finished piece 1 at 14:34:03 18-jan-2005
piece handle=/u01/oracle/archive/controlf_ORA920_04gah12n_4 comment=NONE
channel t1: backup set complete, elapsed time: 00:00:04
Finished backup at 14:34:03 18-jan-2005

Starting Control File Autobackup at 14:34:03 18-jan-2005

piece handle=/optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-01 comment=NONE
Finished Control File Autobackup at 14:34:07 18-jan-2005

released channel: t1
Here is a backup of archived log files
RMAN> run { allocate channel t1 type disk;
2> backup archivelog all format '/u01/oracle/archive/archive_%d_%u_%s' delete input;
3> release channel t1;}

allocated channel: t1
channel t1: sid=26 devtype=DISK
Starting backup at 14:42:00 18-jan-2005
current log archived
channel t1: starting archive log backupset
channel t1: specifying archive log(s) in backup set
input archive log thread=1 sequence=9 recid=1 stamp=547477014
input archive log thread=1 sequence=10 recid=2 stamp=547562627
input archive log thread=1 sequence=11 recid=3 stamp=547562680
input archive log thread=1 sequence=12 recid=4 stamp=547580133
input archive log thread=1 sequence=13 recid=5 stamp=547623518
input archive log thread=1 sequence=14 recid=6 stamp=547744760
input archive log thread=1 sequence=15 recid=7 stamp=547865707
input archive log thread=1 sequence=16 recid=8 stamp=547915324
channel t1: starting piece 1 at 14:42:08 18-jan-2005
channel t1: finished piece 1 at 14:43:03 18-jan-2005
piece handle=/u01/oracle/archive/archive_ORA920_06gah1hv_6 comment=NONE
channel t1: backup set complete, elapsed time: 00:00:56
channel t1: deleting archive log(s)
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_9.arc recid=1
stamp=547477014
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_10.arc recid=2
stamp=547562627
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_11.arc recid=3
stamp=547562680
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_12.arc recid=4
stamp=547580133
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_13.arc recid=5
stamp=547623518
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_14.arc recid=6
stamp=547744760
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_15.arc recid=7
stamp=547865707
archive log filename=/optware/oracle/admin/ORA920/arch/ORA920_1_16.arc recid=8
stamp=547915324
Finished backup at 14:43:04 18-jan-2005
Starting Control File Autobackup at 14:43:04 18-jan-2005
piece handle=/optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-02 comment=NONE
Finished Control File Autobackup at 14:43:09 18-jan-2005

released channel: t1

The rman clauses from logseq and until logseq

Sometimes you will want to backup only certain archived logs and not all. This is the case, for example,
when you ran out of space and you were forced to move the archived logs on disk onto another directory.
In this case the clause "archivelog all" would give an error, because rman will not be able to find the files.
run {
allocate channel dev1 type 'sbt_tape';
backup archivelog
from logseq 12 until logseq 15 thread 1
delete input;
}
Keeping an eye on the list above, the command would back up the archived redo logs from
ORA920_1_12.arc to ORA920_1_15.arc Remember that the name depends on the parameter ... in your
init.ora In our case the values is ...
RMAN> show
2> all;

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # 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 SNAPSHOT CONTROLFILE NAME TO
'/optware/oracle/9.2.0.1/dbs/snapcf_ORA920.f'; # default
RMAN> list backupset ;
List of Backup Sets
===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------
1 Full 269M DISK 00:01:41 14:31:04 18-jan-2005
BP Key: 1 Status: AVAILABLE Tag: TAG20050118T142923
Piece Name: /u01/oracle/archive/ORA920_01gah0q3_1
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- -------------------- ----
1 Full 562946 14:29:24 18-jan-2005 /u01/oradata/ORA920/system01.dbf
2 Full 562946 14:29:24 18-jan-2005 /u02/oradata/ORA920/undo01.dbf
3 Full 562946 14:29:24 18-jan-2005
/u01/oradata/OMF_DATA_ORA920/o1_mf_tools_0ybbwkp7_.dbf
4 Full 562946 14:29:24 18-jan-2005
/u01/oradata/OMF_DATA_ORA920/o1_mf_tbs_data_0ybcd28z_.dbf
5 Full 562946 14:29:24 18-jan-2005
/u01/oradata/ORA920/oem_repository.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------
2 Full 4M DISK 00:00:03 14:31:16 18-jan-2005
BP Key: 2 Status: AVAILABLE Tag: TAG20050118T143112
Piece Name: /u01/oracle/archive/ORA920_02gah0th_2
Controlfile Included: Ckp SCN: 563054 Ckp time: 14:31:13 18-jan-2005

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------
3 Full 4M DISK 00:00:02 14:31:20 18-jan-2005
BP Key: 3 Status: AVAILABLE Tag:
Piece Name: /optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-00
Controlfile Included: Ckp SCN: 563071 Ckp time: 14:31:18 18-jan-2005
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------------
4 Full 4M DISK 00:00:03 14:34:02 18-jan-2005
BP Key: 4 Status: AVAILABLE Tag: TAG20050118T143359
Piece Name: /u01/oracle/archive/controlf_ORA920_04gah12n_4
Controlfile Included: Ckp SCN: 563233 Ckp time: 14:33:59 18-jan-2005

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------
5 Full 4M DISK 00:00:02 14:34:06 18-jan-2005
BP Key: 5 Status: AVAILABLE Tag:
Piece Name: /optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-01
Controlfile Included: Ckp SCN: 563233 Ckp time: 14:33:59 18-jan-2005

BS Key Size Device Type Elapsed Time Completion Time

------- ---------- ----------- ------------ --------------------
6 203M DISK 00:00:56 14:43:03 18-jan-2005
BP Key: 6 Status: AVAILABLE Tag: TAG20050118T144206
Piece Name: /u01/oracle/archive/archive_ORA920_06gah1hv_6

List of Archived Logs in backup set 6

Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- -------------------- ---------- ---------
1 9 118838 12:18:25 13-jan-2005 124198 12:56:51 13-jan-2005
1 10 124198 12:56:51 13-jan-2005 208951 12:43:38 14-jan-2005
1 11 208951 12:43:38 14-jan-2005 209145 12:44:30 14-jan-2005
1 12 209145 12:44:30 14-jan-2005 227914 17:35:21 14-jan-2005
1 13 227914 17:35:21 14-jan-2005 271564 05:38:29 15-jan-2005
1 14 271564 05:38:29 15-jan-2005 392830 15:19:13 16-jan-2005
1 15 392830 15:19:13 16-jan-2005 514138 00:55:00 18-jan-2005
1 16 514138 00:55:00 18-jan-2005 563727 14:42:00 18-jan-2005

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------
7 Full 4M DISK 00:00:02 14:43:07 18-jan-2005
 BP Key: 7 Status: AVAILABLE Tag:
Piece Name: /optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-02
Controlfile Included: Ckp SCN: 563788 Ckp time: 14:43:03 18-jan-2005

RMAN>

Are we sure that our backups do not contain corrupted blocks

There is, of course, little point in taking backups if we don't know whether they are physically usable, i.e.
all their blocks are clean. rman offer the command validate
RMAN> validate backupset 6;

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=26 devtype=DISK
channel ORA_DISK_1: starting validation of archive log backupset
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/oracle/archive/archive_ORA920_06gah1hv_6 tag=TAG20050118T144206
params=NULL
channel ORA_DISK_1: validation complete

RMAN> validate backupset 5;

using channel ORA_DISK_1

channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: restored backup piece 1
piece handle=/optware/oracle/9.2.0.1/dbs/c-2554142925-20050118-01 tag=null
params=NULL
channel ORA_DISK_1: validation complete

RMAN> validate backupset 4;

using channel ORA_DISK_1

channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/oracle/archive/controlf_ORA920_04gah12n_4 tag=TAG20050118T143359
params=NULL
channel ORA_DISK_1: validation complete

Clause not backed up since time

There are cases when backups faile and the stand becomes unclear. To avoid any risk the clause not
backed up since time can be used. This commands makes rman save only the datafiles (or the archived
logs) that haven't be backed up for a certain span of time and skip the rest.
RMAN> run { allocate channel t1 type disk;
2> backup database format '/u01/oracle/archive/%d_%u_%s' not backed up since time
'sysdate -5';
3> release channel t1;}

allocated channel: t1
channel t1: sid=25 devtype=DISK

Starting backup at 15:41:31 21-jan-2005

skipping datafile 1; already backed up on 20:38:51 18-jan-2005
skipping datafile 2; already backed up on 20:38:51 18-jan-2005
skipping datafile 3; already backed up on 20:38:51 18-jan-2005
skipping datafile 4; already backed up on 20:38:51 18-jan-2005
skipping datafile 5; already backed up on 20:38:51 18-jan-2005
Finished backup at 15:41:33 21-jan-2005

released channel: t1

Care is needed for rman restores because they will normally overwrite existing datafiles; before taking any action it is
imperative to understand why a restore is needed and how to proceed.
In our opinion it is better to explain basic rman concepts with understandable examples.
Example 1: a restoration is needed because a datafile is lost.
1. In order to restore a database or a data file some kind of backup must have been taken; in our exaple, let's suppose that our
database consists of three datafiles and that a backup is taken on Mar 10th 2005 in the afternoon.

">

The stand of the datafiles can differ because in general it is not guaranteed that the very last changes in the database have
actually been written to disk. This is why the timestamps 15:09 and 15:15 have been used in the picture.
2. During the week archive log backups are taken daily, for example to tape using the command:
run {
allocate channel t1 type 'sbt_tape';
backup archivelog all delete input;
release channel t1;
}
3. A week later a disk crashes and the database file number 3 is lost:

In this example, it must be understood that only the DBFile3 has to be restored, without overwriting the datafiles that have not
been affected by the crash, or a weeek's work would be lost.
The tablespace containing the damaged file should be put offline with the SQLPLUS command:
SQLPLUS / AS SYSDBA
ALTER TABLESPACE this_tbs OFFLINE IMMEDIATE;

rman target / catalog rman@MYCATALOG

rman> run {
allocate channel t1 type 'sbt_tape';
restore tablespace this_tbs;
release channel t1;
}
If we are sure that only the datafile 3 has been damaged and not the rest of the tablespace this_tbs, we could use instead:
rman> run {
allocate channel t1 type 'sbt_tape';
 restore datafile 3;
release channel t1;
}

It is now obvious that we have a mish-mash of contents, with tablespace up-to-date and a tablespace my_tbs with contents as
of one week before. In this situation, Oracle will refuse to bring the tablespace online, probably with the error message 'datafile
'DBFIle3' needs to be recovered'. How is it possible to bring the tablespace my_tbs at the same stand as for the other
tablespaces? It is possible because we have the archive logs backups, that contain all the changes to the database made
between Mar 10th and Mar 17th.
The command needed is:

run {
allocate channel t1 type 'sbt_tape';
recover database;
release channel t1;
 }
During the execution of this command, rman will restore the archived redo logs and apply them to the damaged tablespace. At
the end of the process the tablespace can be brought online and the database is back to normal.

SQL> shutdown abort .com Search

About DBA Queries DBA Scripts Quick Guides Nooleus Other Stuff Contact
Clone an Oracle database using RMAN duplicate (same server)
tnsManager - Distribute tnsnames the easy way and for free!

This procedure will clone a database onto the same server using RMAN duplicate.

• 1. Backup the source database.

To use RMAN duplicate an RMAN backup of the source database is required. If there is already
one available, skip to step 2. If not, here is a quick example of how to produce an RMAN
backup. This example assumes that there is no recovery catalog available:
• rman target sys@<source database> nocatalog
•
• backup database plus archivelog format '/u01/ora_backup/rman/%d_%u_%s';

This will backup the database and archive logs. The format string defines the location of the
backup files. Alter it to a suitable location.

• 2. Produce a pfile for the new database

This step assumes that the source database is using a spfile. If that is not the case, simply make a
copy the existing pfile.

Connect to the source database as sysdba and run the following:

• create pfile='init<new database sid>.ora' from spfile;

This will create a new pfile in the $ORACLE_HOME/dbs directory.

The new pfile will need to be edited immediately. If the cloned database is to have a different
name to the source, this will need to be changed, as will any paths. Review the contents of the
file and make alterations as necessary.

Because in this example the cloned database will reside on the same machine as the source,
 Copyright© 2007-2010 Andrew Barry

Type of RMAN Backup Tutorial

Full Backups A full backup reads the entire file and copies all blocks into the backup set, only skipping datafile blocks that have
never been used.
About Incremental Backups Rman create backup only changed block since a previous backup. You can use RMAN to create
incremental backups of datafiles, tablespaces, or the whole database.
How Incremental Backups Work
Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to
the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint
SCN of the parent incremental backup. RMAN reads the entire file every time whether or not the blocks have been used.
The parent backup is the backup that RMAN uses for comparing the SCNs. If the current incremental is a differential backup at level
n, then the parent is the most recent incremental of level n or less. If the current incremental is a cumulative backup at level n, then the
parent is the most recent incremental of level n-1 or less. If the SCN in the input data block is greater than or equal to the checkpoint
SCN of the parent, then RMAN copies the block.
Multilevel Incremental Backups
RMAN can create multilevel incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, and so forth.
A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only
difference between a level 0 backup and a full backup is that a full backup is never included in an incremental strategy.
If no level 0 backup exists when you run a level 1 or higher backup, RMAN makes a level 0 backup automatically to serve as the base.
The benefit of performing multilevel incremental backups is that RMAN does not back up all blocks all of the time.
Differential Incremental Backups
In a differential level n incremental backup, RMAN backs up all blocks that have changed since the most recent backup at level n or
lower.
For example, in a differential level 2 backups, RMAN determines which level 2 or level 1 backup occurred most recently and backs up
all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. If no
level 0 backup is available, RMAN makes a new base level 0 backup for this file.
Case 1: if you want to implement incremental backup strategy as a DBA in your organization:
Use Command for incremental Level Backup
RMAN> backup incremental level 0 database tag="SUNDAY";
RMAN> backup incremental level 3 database tag="MONDAY";
RMAN> backup incremental level 3 database tag="TUESDAY";
RMAN> backup incremental level 3 database tag="WEDNESDAY";
RMAN> backup incremental level 2 database tag="THURSDAY";
RMAN> backup incremental level 3 database tag="FRIDAY";
RMAN> backup incremental level 3 database tag="SATURDAY";
Backup Example ( You can view your incremental Backup Details by using following Query)
select incremental_level, incremental_change#, checkpoint_change#, blocks from v$backup_datafile;
Result of above Query:
INC_LEVEL INC_CHANGE# CHECKPOINT_CHANGE# BLOCKS
0 0 271365 59595
3 271365 271369 2
3 271369 271371 1
3 271371 271374 2
2 271365 271378 2
3 271378 271380 1
3 271380 271383 2
Cumulative Incremental Backups
RMAN provides an option to make cumulative incremental backups at level 1 or greater. In a cumulative level n backup, RMAN
backs up all the blocks used since the most recent backup at level n-1 or lower.
For example, in cumulative level 2 backups, RMAN determines which level 1 backup occurred most recently and copies all blocks
changed since that backup. If no level 1 backups is available, RMAN copies all blocks changed since the base level 0 backup.
Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from
any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the
work done by previous backups at the same level.
Case 1: if you want to implement Cumulative backup strategy as a DBA in your organization:
Use Command for Cumulative Level Backup
backup incremental level=0 database tag='base';
backup incremental level=2 cumulative database tag='monday';
backup incremental level=2 cumulative database tag='tuesday';
backup incremental level=2 cumulative database tag='wednesday';
backup incremental level=2 cumulative database tag='thursday';
backup incremental level=2 cumulative database tag='friday';
backup incremental level=2 cumulative database tag='saturday';
backup incremental level=1 cumulative database tag='weekly';
Incremental backup implementation
RMAN will determine the incremental SCN for each datafile
Find the backup with highest checkpoint scn that

• belongs to the incarnation of datafile

• matches the given file#
• is an incremental backup/copy at level N or less if noncumulative or
• is an incremental backup/copy at level N-1 or less if cumulative
• belongs to an available backup set if backup

Incremental Backup Strategy

You can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 backup is taken
weekly, and a cumulative level 2 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete
recovery. When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or
more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental
backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for
each datafile with at least 50% of its blocks backed up:
SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS
FROM V$BACKUP_DATAFILE
WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5
ORDER BY COMPLETION_TIME;
Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1
cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0.