All About RMAN

All About Recovery Manager
Introduction:
This document explains the basic operation of SMR & RMAN. Because of the enormous flexibility of RMAN only the most basic
features will be covered here. For more information, please read the Oracle8 Server Backup & Recovery Guide. For
comprehensive examples, please view the online case*.rcv scripts in $ORACLE_HOME/rdbms/demo.
For the sake of clarity, I have excluded RMAN error messages and return codes unless necessary. It is usually obvious when
an error occurs!
Contents:
1. What is RMAN & SMR?

2. Terminology
3. The recovery catalog
4. Starting RMAN
5. Register the target database
6. Adding existing backups to the recovery catalog
7. Backing up in noarchivelog mode
8. Backing up in archivelog mode
9. Incremental backups
10. Cumulative incremental backups
11. Recovery
12. Scripts
13. Parallelization
14. Corruption detection
15. Channels
16. Balancing throughput on devices
17. Reports
18. Hints, tips, & best practices
All About Recovery Manager Surya Shiva Prasad Battula, CSC India Pvt Ltd.
1. What is RMAN?
RMAN can be used to backup and restore database files, archive logs, and control files. It can also be used to perform
complete or incomplete database recovery. Note that RMAN cannot be used to backup initialization files or password files.
RMAN starts Oracle server processes on the database to be backed up or restored. The backup, restore, and recovery is
driven through these processes hence the term 'server-managed recovery'.
Note that SMR can also be controlled from OEM's Backup Manager GUI. This article will not discuss Backup Manager.
2. Terminology
2.1. Backup sets
A backup set is characterised by the following:
o. Contains one or more datafiles or archivelogs

o. Stored in an Oracle proprietary format
o. Comprises a complete set of backup pieces
o. Constitutes a full or incremental backup
2.2. Backup pieces
A backup set is comprised of a number of backup pieces. Each backup piece is a single output file. The size of a backup
piece an be restricted; if the size is not restricted, the backup set will comprise one backup piece. Backup piece size should be
restricted to no larger than the maximum file size that your filsystem will support.
2.3. Image copies
An image copy is a copy of a single file (datafile, archivelog, or controlfile). It is very similar to an O/S copy of the file. It is not
a backupset or a backup piece. No compression is performed.
2.4. Full backup sets
A full backup is a backup of one or more datafiles that contains all used blocks in the datafile. Blocks that have never been
used are not backed up i.e. oracle performs backup set compression.
2.5. Incremental backup sets
An incremental backup is a backup of one or more datafiles that contains only those blocks that have been modified since a
previous backup at the same or lower level. As with full backups, compression is performed.
2.6. File multiplexing
Datablocks from multiple datafiles can be multiplexed in the same backupset.
2.7. Recovery catalog resyncing
Resyncing the recovery catalog involves sunchronising the recovery catalog with the target database controlfile. Certain
operations perform this implicitly. To resync manually, issue the 'resync catalog;' command from RMAN. The catalog should be
resynced frequently, especially if the target database generates many archive logs. It should also be resynced after making any
structural changes to the target database.
Although the target database's controlfile is automatically updated whenever new controlfile records are created (for example,
creation of new archived logs or new datafiles), if the target is not resync'd and a backup controlfile is restored, the new records
must be cataloged manually (catalog archivelog '<logname>';).
3. The recovery catalog
From the Oracle8 Server Backup & Recovery Guide '..the recovery catalog is a repository of information that is used and
maintained by RMAN. RMAN uses the information in the recovery catalog to determine how to execute requested backup and
restore actions.
The recovery catalog can be in a schema of an existing Oracle8 database. However if RMAN is being used to backup multiple
databases, it is probably worth creating a dedicated recovery catalog database. THE RECOVERY CATALOG
DATABASE CANNOT BE USED TO CATALOG BACKUPS OF ITSELF.
The Oracle8 Server Backup & Recovery Guide p.6-3 lists typical space requirements for the recovery catalog.
To set up the recovery catalog, firstly ensure that catalog and catproc have been run, then execute the following:
SVRMGR> spool create_rman.log
SVRMGR> connect internal
SVRMGR> create user rman identified by rman
temporary tablespace temp
default tablespace rcvcat quota unlimited on rcvcat;
SVRMGR> grant recovery_catalog_owner to rman;
SVRMGR> connect rman/rman
SVRMGR> @?/rdbms/admin/catrman
Check create_rman.log for errors. The above commands assume that the TEMP and RCVCAT tablespaces have been
created.
Also ensure that catproc has been run on the target database; RMAN makes extensive use of RPCs. It is very important that
the recovery catalog database is backed up regularly and frequently.
Note: Although you are not required to use a recovery catalog with RMAN, it is recommended. Because most of the information
in the recovery catalog is available via the target database's controlfile, RMAN can use this information for recovery purposes.
For more information and limitations on using RMAN without a recovery catalog, please see the Oracle8 Server Backup &
Recovery Guide pp.7-8, 7-8.
4. Starting RMAN
RMAN has a command line interface, or can be run from Enterprise Manager. For the purposes of this document, only the CLI
will be covered.
For the purposes of the following examples, assume that

o. the target database is called "targdb" and has the same TNS alias
o. "targdba" has been granted SYSDBA privileges
o. the recovery catalog database is called "rcat" and has the same TNS alias
o. the schema containing the recovery catalog is "rman" (same password)
Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. Much of the RMAN LIST output
is date/time related. It is often necessary to have this information displayed as accurately as possible when performing time-
based recovery. Example NLS settings:
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_FORMAT=DD-MON-YYYY HH24: MI: SS
For RMAN to connect to the recovery catalog and the target database, the recovery catalog database must be OPEN, while
the target instance must be at least STARTED. If not, RMAN will give an error. To perform backups with the target database
open, the target MUST be in archivelog mode.
4.1. Connecting to RMAN without a recovery catalog
Set ORACLE_SID to be the target database, and issue the following:
% rman nocatalog
RMAN> connect target
or if the target database uses a password file,
RMAN> connect target targdba/<password>@targdb
4.2. Connecting to RMAN with a recovery catalog
% rman rcvcat rman/rman@rcat

RMAN> connect target
or if the target database uses a password file,
% rman rcvcat rman/rman@rcat target targdba/<password>@targdb
4.3. Using RMAN
Once connected to the target database, you can specify RMAN commands either interactively or by using stored scripts. An
example of using RMAN interactively would be:
RMAN> resync catalog;
An example of calling a stored script would be:
RMAN> execute script alloc_1_disk;
To create/replace a stored script:
RMAN> replace script alloc_1_disk {

2> allocate channel d1 type disk;
3> }
5. Register the target database
Database status:
Recovery catalog: open
Target: mounted or open
The target database must be registered with the recovery catalog before using RMAN against the database for the first time:
RMAN> register database;
6. Adding existing backups to the recovery catalog
Database status:
Target: mounted or open
If user-created backups existed under version 8.x prior to registering with the target database, these can be added to the
recovery catalog as follows:
RMAN> catalog datafilecopy '/supp/ .... /systargdb.dbf';
To view this file in the catalog, use the following command:
RMAN> list copy of database;
7. Backing up in noarchivelog mode
Database status:
Target: instance started or database mounted
Recovery catalog database is OPEN; target database is started (optionally mounted). Because the target database is not in
archivelog mode, it must not be open when performing backups of datafiles. This would be equivalent of making filesystem
copies of datafiles without putting tablespaces into hot backup mode. If the database is open and not in archivelog mode, RMAN
will generate an error when you attempt to perform a datafile backup
7.1. Example of how to back up a complete database
RMAN> run {
2> # backup the complete database to disk
3> allocate channel dev1 type disk;
4> backup
5> full
6> tag full_db_sunday_night
7> format '/oracle/backups/db_t%t_s%s_p%p'
8> (database);
9> release channel dev1;
10> }
Line#
2: Comment line (anything after the '#' is a comment)
3&9: See section 15 - Channels
5: Full backup (default if full or incremental not specified)
6: Meaningful string (<=30 chars)
7: Filename to use for backup pieces, including substitution variables.
Oracle8 Backup & Recovery Guide p8-26 explains these variables
8: Indicates all files including controlfiles are to be backed up
To view this backup in the catalog, use the following command:
RMAN> list backupset of database;
7.2. Example of how to back up a tablespace
RMAN> run {
3> backup
4> tag tbs_users_read_only
5> format '/oracle/backups/tbs_users_t%t_s%s'
6> (tablespace users);
10> }
Line#
6: Specifying only the USERS tablespace for backup
To view this tablespace backup in the catalog, use the following command:
RMAN> list backupset of tablespace users;
If for example the USERS tablespace is going to be put READ ONLY after being backed up, subsequent full database
backups would not need to backup this tablespace. To cater for this, specify the 'skip readonly’ option in subsequent backups.
Note that although this is a tablespace backup, the target database does NOT have to be open, only mounted. This is
because tablespace information is stored in the controlfile in o8.
7.3. Example of how to backup individual datafiles
RMAN> run {
2> allocate channel dev1 type 'SBT_TAPE';
3> backup
4> format '%d_%u'
5> (datafile '/oracle/dbs/sysbigdb.dbf');
7> }
Line#
2: Allocates a tape drive using the media manager layer (MML)
Note that no tag was specified and is therefore null.
To view this tablespace backup in the catalog, use the following command:
RMAN> list backupset of datafile 1;
7.4. Copying datafiles
RMAN> run {
3> copy datafile '/oracle/dbs/temp.dbf' to '/oracle/backups/temp.dbf';
5> }
To view this file copy in the catalog, use the following command:
RMAN> list copy of datafile '/oracle/dbs/temp.dbf';
Copying a datafile is different to backing up a datafile. A datafile copy is an image copy of the file. A backup of the file creates
a backupset.
7.5. Backing up the controlfile
RMAN> run {
3> backup
4> format 'cf_t%t_s%s_p%p'
5> tag cf_monday_night
6> (current controlfile);
8> }
Note that a database backup will automatically back up the controlfile.
8. Backing up in archivelog mode
Database status:
Target: instance started, database mounted or open
The commands are identical to those in section 7 except that the target
database is in archivelog mode.
8.1. Backing up archived logs
The following script backs up all archive logs:
RMAN> run {
3> backup
4> format '/oracle/backups/log_t%t_s%s_p%p'
5> (archivelog all);
7> }
The following script backs up archive logs from sequence# 90 to 100:
RMAN> run {
3> backup
5> (archivelog from logseq=90 until logseq=100 thread 1);
7> }
The following script backs up all archive logs generated in the past 24 hours. Furthermore it actually deletes the logs after
backing them up. If the backup fails, logs will NOT be deleted:
RMAN> run {
3> backup
5> (archivelog from time 'sysdate-1' all delete input);
7> }
To view the archive logs in the catalog, use the following command:
RMAN> list backupset of archivelog all;
Note that RMAN will backup specified logs if it finds them. If it can't
find a log, it does not issue a warning.
8.2. Backing up the online logs
Online logs CANNOT be backed up using RMAN; they must be archived first. To do this, you can issue SQL commands
from RMAN e.g.
RMAN> run {
3> sql "alter system archive log current";
4> backup
6> (archivelog from time 'sysdate-1' all delete input);
8> }
The above script might be run after performing a full 'database open' backup. It would ensure that all redo to recover the
database to a consistent state would be backed up.
Note, you cannot tag archive log backupsets.
9. Incremental backups
A level N incremental backup backs up blocks that have changed since the
most recent incremental backup at level N or less.
9.1. Level 0 - the basis of the incremental backup strategy
RMAN> run {
3> backup
4> incremental level 0
5> filesperset 4
6> format '/oracle/backups/sunday_level0_%t'
7> (database);
9> }
Line#
4: Level 0 backup - backups of level > 0 can be applied to this
5: Specifies maximum files in the backupset
A list of the database backupsets will show the above backup. The ‘type’ column is marked 'Incremental'; the 'LV' column
shows '0'.
9.2. Example backup strategy using incremental backups
A typical incremental backup cycle would be as follows:
o. Sun night - level 0 backup performed

o. Mon night - level 2 backup performed
o. Tue night - level 2 backup performed
o. Wed night - level 2 backup performed
o. Thu night - level 1 backup performed
o. Fri night - level 2 backup performed
o. Sat night - level 2 backup performed
If the database suffered a failure on Sat morning and this resulted in a restore operation, RMAN could recover to the point of
failure by restoring the backups from Sunday, Thursday, and Friday. This is because Thursdays level 1 backup contains all
changes since Sunday, and Friday's level 2 backup contains all changes since Thursday. Whether the database could be
completely recovered would depend on whether archive logging is enabled.
10. Cumulative incremental backups
A cumulative incremental backup backs up all blocks that have changed since the the most recent incremental backup at level
N-1 or less (contrast with non-cumulative incremental backups that backup blocks that have changed since the the most recent
incremental backup at level N or less). This means that more work is done in performing the backup (duplication of
backup effort), but time may be saved when restoring (potentially fewer backupsets to restore).
11. Recovery
As with backup, recovery is probably best explained with a few examples
11.1. Database open, datafile deleted
Datafile has been deleted from a running database. There are two methods of open database recovery: restore the datafile
and recover either the datafile, or the tablespace. The next two examples show both methods:
(a) Datafile recovery
RMAN> run {
3> sql "alter tablespace users offline immediate";
4> restore datafile 4;
5> recover datafile 4;
6> sql "alter tablespace users online";
8> }
(b) Tablespace recovery
RMAN> run {
3> sql "alter tablespace users offline immediate";
4> restore tablespace users;
5> recover tablespace users;
6> sql "alter tablespace users online";
8> }
Note that if it is the system tablespace datafiles to be restored, the database must be closed. It is not possible to offline the
system tablespace.
11.2. Complete restore (lost online redo) and rollforward - database closed
RMAN> run {
3> set until logseq=105 thread=1;
4> restore controlfile to '/oracle/dbs/ctrltargdb.ctl';
5> replicate controlfile from '/oracle/dbs/ctrltargdb.ctl';
6> restore database;
7> sql "alter database mount";
8> recover database;
9> sql "alter database open resetlogs";
11> }
Notes:
- The 'set until' command dictates at which log sequence recovery will stop. It is critical that this command is issued
BEFORE datafiles are restored, otherwise RMAN will attempt to restore the most recent set of datafiles, which could be ahead of
the specified log - The 'replicate controlfile' copies the restored controlfile to the controlfiles referenced in init.ora Because the
database is opened with resetlogs, it is necessary to register the new incarnation of the database with the RESET DATABASE
command. As with v7, it is important to take a full backup of the database immediately after a resetlogs
11.3. Restore of a subset of datafiles, complete recovery
RMAN> run {
3> sql "alter database mount";
6> restore archivelog all;
7> recover database;
8> sql "alter database open";
10> }
12. Scripts
It is very easy to create and replace stored scripts with RMAN. E.g.
RMAN> create script alloc_disk {

2> # Allocates one disk
4> setlimit channel dev1 kbytes 2097150 maxopenfiles 32 readrate 200;
5> }
RMAN> replace script rel_disk {

2> # releases disk
5> }
RMAN> replace script backup_db_full {

2> # Performs a complete backup
3> execute script alloc_disk;
4> backup
5> .....<backup commands here>
6> execute script rel_disk;
7> }
The first 2 scripts allocate and deallocate channels respectively. The alloc_disk script additionally specifies the maximum size
of backup pieces created on this channel (kbytes), the maximum number of input files that a backup will have open
(maxopenfiles), and the maximum number of buffers per second which will be read from each of the input datafiles.
The 3rd script calls the previously stored scripts either side of performing a backup.
Example of executing a stored script:
RMAN> run {
2> execute script backup_db_full;
3> }
Note that a stored scripts must be called from within a job command
list i.e. run { .... execute <script>; ....}.
It is possible to create a job command list in a flat file and call that script from the O/S command line as an RMAN option. E.g.
to call scripts stored in a file called 'weekly_cold_backup':
% rman <other RMAN options> cmdfile weekly_cold_backup
13. Parallelization
RMAN can parallelize it's operations. When creating backup sets, the granule of parallelization is the backup set. E.g. if your
backup consists of 10 backup sets, RMAN will potentially use 10 channels. To create an environment for this to take place, you
must allocate sufficient channels and dictate the number of backup sets created (using the filesperset parameter). E.g. if you
are backing up a database consisting of 50 datafiles and you allocate 20 channels and specify 'filesperset 10', only 5 channels
will be used. This is because only 5 backup sets (50/10) will be created.
It is also possible to parallelize datafile copy backups by allocating multiple channels, and specifying multiple datafiles in one
copy command.
Please see the Oracle8 Backup and Recovery Guide p.7-20 for examples of parallelization.
14. Corruption detection
SMR will back up datafiles that contain corrupt blocks. However it is possible to set a limit on the number of datablock
corruptions; if this limit is exceeded the backup terminates. The limit is set using the 'set maxcorrupt' clause.
E.g.
RMAN> replace script backup_db_full {

2> # Performs a complete backup
3> execute script alloc_disk;
4> set maxcorrupt for datafile 1 to 0;
5> backup
6>.....<backup commands here>
7> execute script rel_disk;
8> }
When the above script the backup will fail if ANY corrupt blocks are found in datafile 1.
Block corruptions are detected by checksum mismatches during backups. The checksum option is enabled by default but can
be disabled by specifying the 'nochecksum' option.
15. Channels
A channel is a connection from RMAN to a target database. The 'allocate channel' command starts a server process on the
target instance. It also specifies the type of I/O device that the server process will use to perform the backup or restore
operation.
Channel control commands can be used to:
o. Control the O/S resources RMAN uses

o. Affect the degree of parallelism (see section 13)
o. Specify limits on I/O bandwidth (set limit read rate)
o. Specify limits on the size of backup pieces (set limit kbytes)
o. Specify limits on the number of concurrently open files (set limit
maxopenfiles)
See the Oracle8 Server Backup & Recovery pp.7-19, 7-20 for more details
16. Balancing throughput on devices
17. Report & list commands
17.1. List
The list command queries the recovery catalog to produce a formatted listing of contents. E.g.
RMAN> list backupset of datafile 1;
Output:
Key File Type LV Completion_time Ckp SCN Ckp Time

------- ---- ------------ -- --------------- ---------- --------
165 1 Full Oct 03 11:24 32022 Oct 03 11:24
208 1 Full Oct 24 14:27 52059 Oct 24 14:26
219 1 Full Oct 24 14:31 52061 Oct 24 14:31
<< other entries here >>
RMAN> list backupset of archivelog all;
Output:
Key Thrd Seq Completion time

------- ---- ------- ---------------
179 1 94 Oct 03 11:26
179 1 95 Oct 03 11:26
<< other entries here >>
17.2. Report
The report command also queries the recovery catalog; however, the report command syntax is constructed in such a way to
produce a more useful listing. E.g. the following command can be used to list all datafiles in a database that have had
UNRECOVERABLE operations performed on objects in those datafiles since the last backup:
RMAN> report unrecoverable database;
See Oracle8 Server Backup & Recovery Guide pp.8-12, 8-18 for more information on lists and reports.
18. Hints, tips, & best practices
18.1. Resyncing the recovery catalog
It is very important that the recovery catalog be as up to date as possible i.e. it should reflect the state of the target database.
This is achieved by resyncing the catalog from the target controlfile. There are two types of resync operation: full and partial.
Furthermore a resync can be explicit or implicit.
A full resync updates the catalog with ALL controlfile information that has changed since the last resync. This includes
changes to the physical structure of the database. A manual (explicit) resync performs a full resync, whilst full (implicit) resyncs
are performed after an SMR backup.
A partial resync only updates the catalog with redo log, backupset, and datafile copy information i.e. physical structure
changes are NOT refreshed. A partial (implicit) resync is performed before an SMR backup.
At a MINIMUM, you should resync the recovery catalog at intervals less than the init.ora parameter
CONTROL_FILE_RECORD_KEEP_TIME. After this number of days, controlfile information will be overwritten. Because
resyncing is a relatively cheap operation, it is advisable to resync as often as possible, especially if the database switches logs
frequently. The following sample shell script could be scheduled to run hourly:
rman target un/pw@<target alias> rcvcat un/pw@<rcvcat alias> << EOF

resync catalog;
exit;
EOF
18.2. Deleting archive logs
As can be seen from an earlier example, it is possible to direct an SMR server session to delete archived redo logs once they
have been backed up. This option should obviously be used with extreme caution! Only ever delete archivelogs if you are 100%
satisfied that you have good copies/backups elsewhere.
18.3. Keep it simple
As with all backup & recovery strategies, they should be as simple as possible, and should be tested thoroughly.
A few simple stored scripts should be adequate for the vast majority of backup & recovery requirements.
18.4. RMAN errors
When RMAN goes wrong it's spectacular! The error stacks are usually very long. If an error is reported, it is worth getting the
complete stack sent to support as most of the errors will not help in diagnosing the problem.
This Example Explains the RMAN Image copy feature and incrementally updated backups New in
Oracle 10G.
 Rman is configured with Recovery Catalog.
 Recovery Catalog Database Name-Orcl
 Database Name test is taken for demo
 Database Test is Running in no archive log mode
 Configured Backup location is 'D:\ORACLE\RMAN\ORA10G'
 During the first and second run of the backup scripts I have made some changes in the Database.
Also during the second and the third run I made some changes in the Database.
Expanded Image Copying Features: A standard RMAN backup set contains one or more backup pieces, and
each of these pieces consists of the data blocks for a particular datafile stored in a special compressed format. When
a datafile needs to be restored, therefore, the entire datafile essentially needs to be recreated from the blocks
present in the backup piece.
An image copy of a datafile, on the other hand, is much faster to restore because the physical structure of the datafile
already exists. Oracle 10g now permit image copies to be created at the database, tablespace, or datafile level
through the new RMAN directive BACKUP AS COPY. For example, here is a command script to create image
copies for all datafiles in the entire database:
RUN {
# Set the default channel configuration. Note the use of the
# %U directive to insure unique file names for the image copies
ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'D:\oracle\rman\ora10G\U%';
# Create an image copy of all datafiles in the database
BACKUP AS COPY DATABASE;
}
Incrementally Updated Backups: As explained in the previous section, it is now much simpler to create image
copy backups of the database. Another new Oracle 10g feature, incrementally updated backups, allows us to apply
incremental database changes to the corresponding image copy backup - also known as rolling forward the datafile
image copy -- of any datafile in the database. Since image copy backups are much faster to restore in a media
recovery situation, this new feature gives us the option to have updated image copies ready for restoration without
having to recreate the image copies on a regular basis.
To utilize this feature, we will need to use the new BACKUP ... FOR RECOVER OF COPY command to create the
incremental level 1 backups to roll forward the changes to the image copy of the datafiles, and use the new RMAN
RECOVER COPY OF DATABASE command to apply the incremental backup to the image copies of the datafiles.
Note that the TAG directive becomes extremely important to this implementation, as it is used to identify to which
image copies the changes are to be rolled forward.
Here is a script that illustrates a daily cycle of creation and application of the incrementally updated backups. This
would be appropriate for a database that has sufficient disk space for storage of image copies, and has a relatively
high need for quick restoration of media:
Expanded Image Copying Feature
Script1
Rman target backup_admin/backup_admin@test catalog rman/rman@orcl
RUN {
# Roll forward any available changes to image copy files
# From the previous set of incremental Level 1 backups
RECOVER
COPY OF DATABASE
WITH TAG 'cool';
# Create incremental level 1 backup of all datafiles in the database
# For roll-forward application against image copies
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'cool'
DATABASE;
Note- backup_admin user connect to the target database and Rman user connect to the catalog
Operation of the script is explained.
First run of Script1:
 The RECOVER command actually has no effect, because it cannot find any incremental backups with a tag
of cool.
 However, the BACKUP command will create a new Incremental Level 0 backup that is labeled with a tag of
cool because no backups have been created yet with this tag.
Second run of Script1:
 The RECOVER command still will have no effect, because it cannot find any Level 1 incremental backups
with a tag of cool.
 The BACKUP command will create its first Incremental Level 1 backup that is labeled with a tag of cool.
Third and subsequent runs of the Script1:
 The RECOVER command finds the incremental level 1 image copy backups from the previous night's run
tagged as cool, and applies them to the existing datafile image copies.
 The BACKUP command will create the next Incremental Level 1 backup that is labeled with a tag of cool.
First Run Output
RMAN> RUN {
2> # Roll forward any available changes to image copy files
3> # from the previous set of incremental Level 1 backups
4> RECOVER
5> COPY OF DATABASE
6> WITH TAG 'cool';
7>
8> # Create incremental level 1 backup of all datafiles in the database
9> # for roll-forward application against image copies
10> BACKUP
11> INCREMENTAL LEVEL 1
12> FOR RECOVER OF COPY WITH TAG 'cool'
13> DATABASE;
14>};
Starting recover at 13-APR-06

using channel ORA_DISK_1
no copy of datafile 1 found to recover
Finished recover at 13-APR-06
Starting backup at 13-APR-06
no parent backup or copy of datafile 1 found
channel ORA_DISK_1: starting datafile copy
input datafile fno=00001 name=D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF
output filename=D:\ORACLE\RMAN\ORA10G\BACKUP_DB_TEST_S_55_P_1_T_587658980 tag=CO
OL recid=54 stamp=587659007
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:35
input datafile fno=00003 name=D:\ORACLE\ORADATA\TEST\SYSAUX01.DBF
input datafile fno=00005 name=D:\ORACLE\ORADATA\TEST\EXAMPLE01.DBF
input datafile fno=00002 name=D:\ORACLE\ORADATA\TEST\UNDOTBS01.DBF
input datafile fno=00004 name=D:\ORACLE\ORADATA\TEST\USERS01.DBF
channel ORA_DISK_1: starting incremental level 1 datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 13-APR-06
channel ORA_DISK_1: finished piece 1 at 13-APR-06
piece handle=D:\ORACLE\RMAN\ORA10G\BACKUP_DB_TEST_S_60_P_1_T_587659042 tag=TAG20
060413T143619 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 13-APR-06
************************************************************************************************************
Second Run Output
RMAN> RUN {
4> RECOVER
5> COPY OF DATABASE
6> WITH TAG 'cool';
7>
10> BACKUP
13> DATABASE;
14>};
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK

************************************************************************************************************
Third Run Output
RMAN> RUN {
4> RECOVER
5> COPY OF DATABASE
6> WITH TAG 'cool';
7>
10> BACKUP
13> DATABASE;
14> };

channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy fno=00001 name=D:\ORACLE\RMAN\ORA10G\BACKUP_DB_TEST_S_5
5_P_1_T_587658980
8_P_1_T_587659037
6_P_1_T_587659015
9_P_1_T_587659041
7_P_1_T_587659030
channel ORA_DISK_1: reading from backup piece D:\ORACLE\RMAN\ORA10G\BACKUP_DB_TE
ST_S_61_P_1_T_587659454
channel ORA_DISK_1: restored backup piece 1
060413T144414
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04

************************************************************************************************************
I have deleted the database including the current spfile
Restore operation
Spfile Restore
rman target backup_admin/backup_admin@test catalog rman/rman@orcl
RMAN> run {
2> restore spfile to 'd:\spfile';
3> }
Starting restore at 13-APR-06

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: restoring SPFILE
output filename=d:\spfile.ora
ST_S_64_P_1_T_587659742
060413T144837
Finished restore at 13-APR-06
************************************************************************************************************
Restore Controlfile
RMAN> run {
2> restore controlfile;
3>};

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: restoring control file
ST_S_64_P_1_T_587659742
060413T144837
output filename=D:\ORACLE\ORADATA\TEST\CONTROL01.CTL
************************************************************************************************************
Database Restore
(It will restore the last image copy backup of the Database, which is already been recovered with all
incremental backup except the latest one).
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> run {
2> restore database;
3> }

channel ORA_DISK_1: restoring datafile 00001

input datafile copy recid=63 stamp=587659714 filename=D:\ORACLE\RMAN\ORA10G\BACK
UP_DB_TEST_S_55_P_1_T_587658980
destination for restore of datafile 00001: D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF
channel ORA_DISK_1: copied datafile copy of datafile 00001
output filename=D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF recid=64 stamp=587660786
UP_DB_TEST_S_58_P_1_T_587659037
destination for restore of datafile 00002: D:\ORACLE\ORADATA\TEST\UNDOTBS01.DBF
output filename=D:\ORACLE\ORADATA\TEST\UNDOTBS01.DBF recid=65 stamp=587660796
UP_DB_TEST_S_56_P_1_T_587659015
destination for restore of datafile 00003: D:\ORACLE\ORADATA\TEST\SYSAUX01.DBF
output filename=D:\ORACLE\ORADATA\TEST\SYSAUX01.DBF recid=66 stamp=587660811
UP_DB_TEST_S_59_P_1_T_587659041
destination for restore of datafile 00004: D:\ORACLE\ORADATA\TEST\USERS01.DBF
output filename=D:\ORACLE\ORADATA\TEST\USERS01.DBF recid=67 stamp=587660813
UP_DB_TEST_S_57_P_1_T_587659030
destination for restore of datafile 00005: D:\ORACLE\ORADATA\TEST\EXAMPLE01.DBF
output filename=D:\ORACLE\ORADATA\TEST\EXAMPLE01.DBF recid=68 stamp=587660819
Recover the Database:

It will apply the last incremental backup to the Database.
RMAN> recover database;

channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF
destination for restore of datafile 00002: D:\ORACLE\ORADATA\TEST\UNDOTBS01.DBF
destination for restore of datafile 00003: D:\ORACLE\ORADATA\TEST\SYSAUX01.DBF
destination for restore of datafile 00004: D:\ORACLE\ORADATA\TEST\USERS01.DBF
destination for restore of datafile 00005: D:\ORACLE\ORADATA\TEST\EXAMPLE01.DBF
ST_S_63_P_1_T_587659717
060413T144837
starting media recovery
archive log thread 1 sequence 64 is already on disk as file D:\ORACLE\ORADATA\TE

ST\LOG5.DBF
archive log filename=D:\ORACLE\ORADATA\TEST\LOG5.DBF thread=1 sequence=64
media recovery complete, elapsed time: 00:00:01
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalogstarting full resync of recovery catalog full resync
complete
Reference: www.metalink.oracle.com, www.dba-village.com

All About RMAN

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

All About RMAN

Cargado por

Copyright:

Formatos disponibles

All About Recovery Manager

1. What is RMAN & SMR?

2.1. Backup sets

A backup set is characterised by the following:

o. Contains one or more datafiles or archivelogs

2.2. Backup pieces

2.3. Image copies

2.4. Full backup sets

2.5. Incremental backup sets

2.6. File multiplexing

Datablocks from multiple datafiles can be multiplexed in the same backupset.

2.7. Recovery catalog resyncing

3. The recovery catalog

For the purposes of the following examples, assume that

4.1. Connecting to RMAN without a recovery catalog

Set ORACLE_SID to be the target database, and issue the following:

4.2. Connecting to RMAN with a recovery catalog

% rman rcvcat rman/rman@rcat

4.3. Using RMAN

RMAN> resync catalog;

An example of calling a stored script would be:

RMAN> execute script alloc_1_disk;

To create/replace a stored script:

RMAN> replace script alloc_1_disk {

5. Register the target database

RMAN> register database;

6. Adding existing backups to the recovery catalog

RMAN> catalog datafilecopy '/supp/ .... /systargdb.dbf';

To view this file in the catalog, use the following command:

RMAN> list copy of database;

7. Backing up in noarchivelog mode

7.1. Example of how to back up a complete database

To view this backup in the catalog, use the following command:

RMAN> list backupset of database;

7.2. Example of how to back up a tablespace

RMAN> list backupset of tablespace users;

7.3. Example of how to backup individual datafiles

RMAN> list backupset of datafile 1;

RMAN> list copy of datafile '/oracle/dbs/temp.dbf';

7.5. Backing up the controlfile

Note that a database backup will automatically back up the controlfile.

8. Backing up in archivelog mode

8.1. Backing up archived logs

The following script backs up all archive logs:

The following script backs up archive logs from sequence# 90 to 100:

8.2. Backing up the online logs

Note, you cannot tag archive log backupsets.

9.1. Level 0 - the basis of the incremental backup strategy

9.2. Example backup strategy using incremental backups

A typical incremental backup cycle would be as follows:

o. Sun night - level 0 backup performed

10. Cumulative incremental backups

As with backup, recovery is probably best explained with a few examples

11.1. Database open, datafile deleted

(a) Datafile recovery

(b) Tablespace recovery

11.3. Restore of a subset of datafiles, complete recovery

RMAN> create script alloc_disk {

RMAN> replace script rel_disk {

RMAN> replace script backup_db_full {

Example of executing a stored script:

% rman <other RMAN options> cmdfile weekly_cold_backup