RMAN

Basic RMAN Tutorial
Oracle provide a tool for Database backup and restore operation is called RMAN.
Recovery Manager is a client/server application that uses database server sessions to
perform backup and recovery. It stores metadata about its operations in the control file
of the target database and, optionally, in a recovery catalog schema in an Oracle
database.
Difference between RMAN and Traditional backup methods
RMAN is Oracle's backup and recovery utility. With RMAN, backups become as easy as:
BACKUP DATABASE;
RMAN reduces the complexity of backup and recovery. RMAN can determine what
needs to be backed up or restored.
Why Should we use RMAN
Ability to perform incremental backups.
Ability to recover one block of a datafile.
Ability to perform the backup and restore with parallelization.
Ability to automatically delete archived redo logs after they are backed up.
Ability to automatically backup the control file and the SPFILE.
Ability to restart a failed backup without having to start from the beginning.
Ability to verify the integrity of the backup.
Ability to test the restore process without having to actually perform the restore.
Comparison of RMAN Automated and User-Managed Procedures
By using operating system commands for User-Managed Backup and Recovery , a DBA
manually keeps track of all database files and backups. But RMAN performs these same
tasks automatically.
Understanding the RMAN Architecture
An oracle RMAN comprises of RMAN EXECUTABLE This could be present and fired even
through client side, TARGET DATABASE (This is the database which needs to be backed
up) and RECOVERY CATALOG (Recovery catalog is optional otherwise backup details are
stored in target database controlfile .)
About the RMAN Repository
The RMAN repository is a set of metadata that RMAN uses to store information about
the target database and its backup and recovery operations. RMAN stores information
about:
Backup sets and pieces
Image copies (including archived redo logs)
Proxy copies
The target database schema
Persistent configuration settings
If you start RMAN without specifying either CATALOG or NOCATALOG on the command
line, then RMAN makes no connection to a repository. If you run a command that
requires the repository, and if no CONNECT CATALOG command has been issued yet,
then RMAN automatically connects in the default NOCATALOG mode. After that point,
the CONNECT CATALOG command is not valid in the session.
Types of Database Connections
You can connect to the following types of databases.
Target database
RMAN connects you to the target database with the SYSDBA privilege. If you do not
have this privilege, then the connection fails.
Recovery catalog database
This database is optional: you can also use RMAN with the default NOCATALOG option.
Auxiliary database
You can connect to a standby database, duplicate database, or auxiliary instance
(standby instance or tablespace point-in-time recovery instance
Note: That a SYSDBA privilege is not required when connecting to the recovery
catalog. The only requirement is that the RECOVERY_CATALOG_OWNER role be granted
to the schema owner.
Using Basic RMAN Commands
After you have learned how to connect to a target database, you can immediately
begin performing backup and recovery operations. Use the examples in this section to
go through a basic backup and restore scenario using a test database. These examples
assume the following:
The test database is in ARCHIVELOG mode.
You are running in the default NOCATALOG mode.
The RMAN executable is running on the same host as the test database.
Connecting to the Target Database
rman TARGET /
If the database is already mounted or open, then RMAN displays output similar to the
following:
Recovery Manager: Release 9.2.0.0.0
connected to target database: RMAN (DBID=1237603294)
Reporting the Current Schema of the Target Database
In this example, you generate a report describing the target datafiles. Run the report
schema command as follows:
RMAN> REPORT SCHEMA; (RMAN displays the datafiles currently in the target
database.)
Backing Up the Database
In this task, you back up the database to the default disk location. Because you do not
specify the format parameter in this example, RMAN assigns the backup a unique
filename.
You can make two basic types of backups: full and incremental.
Making a Full Backup

Run the backup command at the RMAN prompt as follows to make a full backup of the
datafiles, control file, and current server parameter file (if the instance is started with a
server parameter file) to the default device type:
RMAN> BACKUP DATABASE;
Making an Incremental Backup
Incremental backups are a convenient way to conserve storage space because they
back up only database blocks that have changed. RMAN compares the current datafiles
to a base backup, also called a level 0 backup, to determine which blocks to back up.
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
Backing Up Archived Logs
Typically, database administrators back up archived logs on disk to a third-party
storage medium such as tape. You can also back up archived logs to disk. In either
case, you can delete the input logs automatically after the backup completes.To back
up all archived logs and delete the input logs (from the primary archiving destination
only), run the backup command at the RMAN prompt as follows:
RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;
Listing Backups and Copies
To list the backup sets and image copies that you have created, run the list command
as follows:
RMAN> LIST BACKUP;
To list image copies, run the following command:
RMAN> LIST COPY;
Validating the Restore of a Backup
Check that you are able to restore the backups that you created without actually restoring them. Run
the RESTORE ... VALIDATE command as follows:
RMAN> RESTORE DATABASE VALIDATE;
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
Backup Example ( You can view
following Query)
database tag="SUNDAY";
database tag="MONDAY";
database tag="TUESDAY";
database tag="WEDNESDAY";
database tag="THURSDAY";
database tag="FRIDAY";
database tag="SATURDAY";
your incremental Backup Details by using
select incremental_level, incremental_change#, checkpoint_change#, blocks from

v$backup_datafile;
Result of above Query:
INC_LEVEL
0
3
3
3
2
3
3
INC_CHANGE#
0
271365
271369
271371
271365
271378
271380
CHECKPOINT_CHANGE#
271365
271369
271371
271374
271378
271380
271383
BLOCKS
59595
2
1
2
2
1
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.
RMAN: RESTORE Concept

Use the RMAN RESTORE command to restore the following types of files from copies
on disk or backups on other media:
Database (all datafiles)
Tablespaces
Control files
Archived redo logs
Server parameter files
Process of Restore Operations
RMAN automates the procedure for restoring files. When you issue a RESTORE
command, RMAN restore the correct backups and copies to either:
The default location, overwriting the old files with the same name
A new location, which you can specify with the SET NEWNAME command
For example:
If you restore datafile 'C:_DATA.DBF to its default location, then RMAN restores the file
C:_DTAA.DBF and overwrites any file that it finds with the same filename.
if you run a SET NEWNAME command before you restore a file, then RMAN creates a
datafile copy with the name that you specify. For example, assume that you run the
following commands:
Run
{
SET NEWNAME FOR DATAFILE 'C:_DATA.DBF TO C:_DATA.DBF;
RESTORE DATAFILE 'C:_DTAA.DBF;
SWITCH DATAFILE 'C:_DATA.DBF' TO DATAFILECOPY 'C:_DATA.DBF;
}
In this case, RMAN creates a datafile copy of 'C:_DATA.DBF named 'C:_DATA.DBF
and records it in the repository. To change the name for datafile 'C:_DATA.DBF to
'C:_DATA.DBF in the control file, run a SWITCH command so that RMAN considers the
restored file as the current database file.
RMAN Recovery: Basic Steps
If possible, make the recovery catalog available to perform the media recovery. If it is
not available, then RMAN uses metadata from the target database control file.
Assuming that you have backups of the datafiles and at least one autobackup of the
control file.
The generic steps for media recovery using RMAN are as follows:
Place the database in the appropriate state: mounted or open.
For example, mount the database when performing whole
database recovery, or open the database when performing
online tablespace recovery.
Restore the necessary files using the RESTORE command.
Recover the datafiles using the RECOVER command.
Place the database in its normal state.
Mechanism of Restore and Recovery operation:
The DBA runs the following commands:
RESTORE DATABASE;
RECOVER DATABASE;
The RMAN recovery catalog obtains its metadata from the target database control file.
RMAN decides which backup sets to restore, and which incremental backups and
archived logs to use for recovery. A server session on the target database instance
performs the actual work of restore and recovery.
Mechanics of Recovery: Incremental Backups and Redo Logs
RMAN does not need to apply incremental backups to a restored level 0 incremental
backup: it can also apply archived logs. RMAN simply restores the datafiles that it
needs from available backups and copies, and then applies incremental backups to the
datafiles if it can and if not applies logs.
How RMAN Searches for Archived Redo Logs During Recovery
If RMAN cannot find an incremental backup, then it looks in the repository for the
names of archived redo logs to use for recovery. Oracle records an archived log in the
control file whenever one of the following occurs:
The archiver process archives a redo log
RMAN restores an archived log
The RMAN COPY command copies a log
The RMAN CATALOG command catalogs a user-managed backup of an
archived log
RMAN propagates archived log data into the recovery catalog during resynchronization,
classifying archived logs as image copies. You can view the log information through:
The LIST command
The V$ARCHIVED_LOG control file view
The RC_ARCHIVED_LOG recovery catalog view
During recovery, RMAN looks for the needed logs using the filenames specified in the
V$ARCHIVED_LOG view. If the logs were created in multiple destinations or were generated
by the COPY, CATALOG, or RESTORE commands, then multiple, identical copies of each log
sequence number exist on disk.
If the RMAN repository indicates that a log has been deleted or uncataloged, then RMAN
ceases to consider it as available for recovery. For example, assume that the database
archives log 100 to directories /dest1 and /dest2. The RMAN repository indicates that
/dest1/log100.arc and /dest2/log100.arc exist. If you delete /dest1/log100.arc with the
DELETE command, then the repository indicates that only /dest2/log100.arc is available for
recovery.
If the RMAN repository indicates that no copies of a needed log sequence number exist on
disk, then RMAN looks in backups and restores archived redo logs as needed to perform the
media recovery. By default, RMAN restores the archived redo logs to the first local archiving
destination specified in the initialization parameter file. You can run the SET ARCHIVELOG
DESTINATION command to specify a different restore location. If you specify the DELETE
ARCHIVELOG option on RECOVER, then RMAN deletes the archived logs after restoring and
applying them. If you also specify MAXSIZE integer on the RECOVER command, then RMAN
staggers the restores so that they consume no more than integer amount of disk space at a
time.
Incomplete Recovery
RMAN can perform either complete or incomplete recovery. You can specify a time,
SCN, or log sequence number as a limit for incomplete recovery with the SET UNTIL
command or with an UNTIL clause specified directory on the RESTORE and RECOVER
commands. After performing incomplete recovery, you must open the database with
the RESETLOGS option.
Disaster Recovery with a Control File Autobackup
Assume that you lose both the target database and the recovery catalog. All that you
have remaining is a tape with RMAN backups of the target database and archived redo
logs. Can you still recover the database? Yes, assuming that you enabled the control file
autobackup feature. In a disaster recovery situation, RMAN can determine the name of
a control file autobackup even without a repository available. You can then restore this
control file, mount the database, and perform media recovery.
About Block Media Recovery
You can also use the RMAN BLOCKRECOVER command to perform block media
recovery. Block media recovery recovers an individual corrupt datablock or set of
datablocks within a datafile. In cases when a small number of blocks require media
recovery, you can selectively restore and recover damaged blocks rather than whole
datafiles.
Note: Restrictions of block media recovery:
You can only perform block media recovery with Recovery Manager. No SQL*Plus recovery
interface is available.
You can only perform complete recovery of individual blocks. In other words, you cannot stop
recovery before all redo has been applied to the block.
You can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION view
indicates which blocks in a file were marked corrupt since the most recent BACKUP, BACKUP ...
VALIDATE, or COPY command was run against the file.
You must have a full RMAN backup. Incremental backups are not allowed.
Blocks that are marked media corrupt are not accessible to users until recovery is complete. Any
attempt to use a block undergoing media recovery results in an error message indicating that the
block is media corrupt.
When Block Media Recovery Should Be Used

For example, you may discover the following messages in a user trace file:
ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'
You can then specify the corrupt blocks in the BLOCKRECOVER command as follows:
BLOCKRECOVER DATAFILE 7 BLOCK 3 DATAFILE 2 BLOCK 235;
Block Media Recovery When Redo Is Missing
Like datafile media recovery, block media recovery cannot survive a missing or
inaccessible archived log. Where is datafile recovery requires an unbroken series of
redo changes from the beginning of recovery to the end, block media recovery only
requires an unbroken set of redo changes for the blocks being recovered.
When RMAN first detects missing or corrupt redo records during block media recovery, it does not
immediately signal an error because the block undergoing recovery may become a newed block later in
the redo stream. When a block is newed all previous redo for that block becomes irrelevant because the
redo applies to an old incarnation of the block. For example, Oracle can new a block when users delete
all the rows recorded in the block or drop a table.
RMAN Other Tutorial

Deciding Whether to Use RMAN with a Recovery Catalog
By default, RMAN connects to the target database in NOCATALOG mode, meaning
that it uses the control file in the target database as the sole repository of RMAN
metadata. Perhaps the most important decision you make when using RMAN is
whether to create a recovery catalog as the RMAN repository for normal production
operations. A recovery catalog is a schema created in a separate database that
contains metadata obtained from the target control file.
Benefits of Using the Recovery Catalog as the RMAN Repository
When you use a recovery catalog, RMAN can perform a wider variety of automated
backup and recovery functions than when you use the control file in the target
database as the sole repository of metadata.
The following features are available only with a catalog:
You can store metadata about multiple target databases in a single catalog.
You can store metadata about multiple incarnations of a single target database in
the catalog. Hence, you can restore backups from any incarnation.
Resynchronizing the recovery catalog at intervals less than the
CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
You can report the target database schema at a noncurrent time.
You can store RMAN scripts in the recovery catalog.
When restoring and recovering to a time when the database files that exist in the database are
different from the files recorded in the mounted control file, the recovery catalog specifies which
files that are needed. Without a catalog, you must first restore a control file backup that lists the
correct set of database files.
If the control file is lost and must be restored from backup, and if persistent configurations have
been made to automate the tape channel allocation, these configurations are still available when
the database is not mounted.
Costs of Using the Recovery Catalog as the RMAN Repository

The main cost of using a catalog is the maintenance overhead required for this
additional database.
For example, you have to:Find a database other than the target database to store the
recovery catalog (otherwise, the benefits of maintaining the catalog are lost), or create
a new database Create enough space on the database for the RMAN metadata.
Back up the recovery catalog metadata

Upgrade the recovery catalog when necessary
Types of Files That RMAN Can Back Up The BACKUP command can back up the
following types of files:
Database, which includes all datafiles as well as the current control file and current
server parameter
file:
Tablespaces (except for locally-managed temporary tablespaces)

Current datafiles
Current control file
Archived redo logs
Current server parameter file
Backup sets
RMAN does not back up the following:

Online redo logs
Transported tablespaces before they have been made read/write
Client-side initialization parameter files or noncurrent server parameter files
How to Configure RMAN

RMAN can invoked from the command line on the database host machine like so:
C:\>rman target sys/sys_password
Recovery Manager: Release 9.2.0.1.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
Connected to target database: ORCL (DBID=1036216947)

RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
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
'e:\backup\ctl_sp_bak_%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G;
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\ORA92\DATABASE\SNCFORCL.ORA'; #
default
RMAN>
Retention Policy:
This instructs RMAN on the backups that are eligible for deletion.
For example: A retention policy with redundancy 2 would mean that two backups - the latest and the
one prior to that - should be retained. All other backups are candidates for deletion.
Default Device Type:
This can be "disk" or "sbt" (system backup to tape). We will backup to disk and then have our OS
backup utility copy the completed backup, and other supporting files, to tape.
Controlfile Autobackup:
This can be set to "on" or "off". When set to "on", RMAN takes a backup of the controlfile AND server
parameter file each time a backup is performed. Note that "off" is the default.
Controlfile Autobackup Format:
This tells RMAN where the controlfile backup is to be stored. The "%F" in the file name instructs RMAN to
append the database identifier and backup timestamp to the backup filename. The database identifier, or
DBID, is a unique integer identifier for the database.
Parallelism:
This tells RMAN how many server processes you want dedicated to performing the backups.
Device Type Format:

This specifies the location and name of the backup files. We need to specify the
format for each channel. The "%U" ensures that Oracle appends a unique identifier to the backup file
name. The MAXPIECESIZE attribute sets a maximum file size for each file in the backup set.
Any of the above parameters can be changed using the commands displayed by the "show all"
command.
For example, one can turn off controlfile autobackups by issuing:
RMAN> configure controlfile autobackup off;

using target database controlfile instead of recovery catalog
old RMAN configuration parameters:
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
new RMAN configuration parameters are successfully stored
Complete Steps for Using RMAN through Catalog

Recovery manager is a platform independent utility for coordinating your backup and
restoration procedures across multiple servers.
Create Recovery Catalog
First create a user to hold the recovery catalog:
CONNECT sys/password@w2k1 AS SYSDBA
Create tablepsace to hold repository
CREATE TABLESPACE "RMAN" DATAFILE 'C:\ORACLE\ORADATA\W2K1\RMAN01.DBF' SIZE
6208K REUSE AUTOEXTEND ON NEXT 64K MAXSIZE 32767M EXTENT MANAGEMENT
LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
Create rman schema owner
CREATE USER rman IDENTIFIED BY rman TEMPORARY TABLESPACE temp DEFAULT
TABLESPACE rman QUOTA UNLIMITED ON rman;
GRANT connect, resource, recovery_catalog_owner TO rman;
Then create the recovery catalog:
C:>rman catalog=rman/rman@w2k1
Connected to recovery catalog database
Recovery catalog is not installed
RMAN> create catalog tablespace "RMAN";

Recovery catalog created
RMAN> exit
Recovery Manager complete.
Register Database
Each database to be backed up by RMAN must be registered:
C:>rman catalog=rman/rman@w2k1 target=sys/password@w2k2\
<mailto:target=sys/password@w2k2\>

connected to target database: W2K2 (DBID=1371963417)
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN>
Full Backup
First we configure several persistent parameters for this instance:
RMAN> configure retention policy to recovery window of 7 days;
RMAN> configure default device type to disk;
RMAN> configure controlfile autobackup on;
RMAN> configure channel device type disk format
'C:\Oracle\Admin\W2K2\Backup%d_DB_%u_%s_%p';
Next we perform a complete database backup using a single command:
RMAN> run
{backup database plus archivelog;
delete noprompt obsolete;
}
The recovery catalog should be resyncronized on a regular basis so that changes to the
database structure and presence of new archive logs is recorded. Some commands
perform partial and full resyncs implicitly, but if you are in doubt you can perform a full
resync using the follwoing command:
RMAN> resync catalog;
RMAN CASE STUDY

REDO FILE RECOVERY
Recovery from missing or corrupted redo log group
Case 1: A multiplexed copy of the missing log is available.

If a redo log is missing, it should be restored from a multiplexed copy, if possible. Here's
an example, where I attempt to startup from SQLPLUS when a redo log is missing:
SQL> startup
ORACLE instance started.
Total System Global Area 131555128 bytes
Fixed Size 454456 bytes
Variable Size 88080384 bytes
Database Buffers 41943040 bytes
Redo Buffers 1077248 bytes
Database mounted.
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: 'D:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG'
SQL>
To fix this we simply copy REDO03A.LOG from its multiplexed location on E: to the
above location on D:.
SQL> alter database open;
Database altered.
Case 2: All members of a log group lost.
In this case an incomplete recovery is the best we can do. We will lose all transactions
from the missing log and all subsequent logs. We illustrate using the same example as
above. The error message indicates that members of log group 3 are missing. We don't
have a copy of this file, so we know that an incomplete recovery is required. The first
step is to determine how much can be recovered. In order to do this, we query the
V$LOG view (when in the mount state) to find the system change number (SCN) that
we can recover to (Reminder: the SCN is a monotonically increasing number that is
incremented whenever a commit is issued)
--The database should be in the mount state for v$log access
SQL> select first_change# from v$log whnhi.ere group#=3 ;
FIRST_CHANGE#
------------370255
SQL>
The FIRST_CHANGE# is the first SCN stamped in the missing log. This implies that the
last SCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest
SCN that we can recover to. In order to do the recovery we must first restore ALL
datafiles to this SCN, followed by recovery (also up to this SCN). This is an incomplete
recovery, so we must open the database resetlogs after we're done. Here's a transcript
of the recovery session (typed commands in bold, comments in italics, all other lines
are RMAN feedback):
C:\>rman target /
connected to target database: ORCL (DBID=1507972899)
--Restore ENTIRE database to determined SCN
RMAN> restore database until scn 370254;
Starting restore at 26/JAN/05
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBF
restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF
restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF
restoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF
channel ORA_DISK_2: restored backup piece 1
piece handle=E:\BACKUP\13GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL
channel ORA_DISK_2: restore complete
piece handle=E:\BACKUP\14GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL
Finished restore at 26/JAN/05
--Recover database
RMAN> recover database until scn 370254;
Starting recover at 26/JAN/05

starting media recovery
archive log thread 1 sequence 9 is already on disk as file
E:\ORACLE_ARCHIVE\ORCL\1_9.ARC
media recovery complete
Finished recover at 26/JAN/05
--open database with RESETLOGS (see comments below)
RMAN> alter database open resetlogs;
database opened
RMAN>
The following points should be noted:
1. The entire database must be restored to the SCN that has been determined by
querying v$log.
2. All changes beyond that SCN are lost. This method of recovery should be used only if
you are sure that you cannot do better. Be sure to multiplex your redo logs, and (space
permitting) your archived logs!
3. The database must be opened with RESETLOGS, as a required log has not been
applied. This resets the log sequence to zero, thereby rendering all prior backups
worthless. Therefore, the first step after opening a database RESETLOGS is to take a
fresh backup. Note that the RESETLOGS option must be used for any incomplete
recovery.
CONTROL FILE RECOVERY

Recovery from missing or corrupted control file
Case 1: A multiplexed copy of the control file is available.
On startup Oracle must read the control file in order to find out where the datafiles and
online logs are located. Oracle expects to find control files at locations specified in the
CONTROL_FILE initialisation parameter. The instance will fail to mount the database if
any one of the control files are missing or corrupt. Here's an example:
SQL> startup

ORA-00205: error in identifying controlfile, check alert log for more info
SQL>
On checking the alert log, as suggested, we find the following:
ORA-00202: controlfile: 'e:\oracle_dup_dest\controlfile\ORCL\control02.ctl'
ORA-27046: file size is not a multiple of logical block size
OSD-04012: file size mismatch (OS 5447783)
The above corruption was introduced by manually editing the control file when the
database was closed.
The solution is simple, provided you have at least one uncorrupted control file - replace
the corrupted control file with a copy using operating system commands. Remember to
rename the copied file. The database should now start up without any problems.
Case 2: All control files lost

What if you lose all your control files? In that case you have no option but to use a
backup control file. The recovery needs to be performed from within RMAN, and
requires that all logs (archived and current online logs) since the last backup are
available. The logs are required because all datafiles must also be restored from
backup. The database will then have to be recovered up to the time the control files
went missing. This can only be done if all intervening logs are available. Here's an
annotated transcript of a recovery session (as usual, lines in bold are commands to be
typed, lines in italics are explanatory comments, other lines are RMAN feedback):
Connect to RMAN
C:\rman
(c) Copyright 2001 Oracle Corporation. All rights reserved.
RMAN> set dbid 4102753520
executing command: SET DBID
set DBID - get this from the name of the controlfile autobackup. For example, if
autobackup name is
CTL_SP_BAK_C-1507972899-20050124-00 the the DBID is 1507972899. This step will
not be required if the instance is
RMAN> connect target sys/change_on_install
connected to target database: (not mounted)

connected to target database: ORCL (not mounted)
RMAN> restore controlfile from autobackup;
channel ORA_DISK_1: restoring controlfile
replicating controlfile
input filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTL
output filename=E:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL02.CTL
output filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTL
-- Now that control files have been restored, the instance can mount the
-- database.
RMAN> mount database;
database mounted
-- All datafiles must be restored, since the controlfile is older than the current
-- datafiles. Datafile restore must be followed by recovery up to the current log.
RMAN> restore database;

--Database must be recovered because all datafiles have been restored from
-- backup
RMAN> recover database;
D:\ORACLE_DATA\LOGS\ORCL\REDO02A.LOG
D:\ORACLE_DATA\LOGS\ORCL\REDO01A.LOG

-- Recovery completed. The database must be opened with RESETLOGS
-- because a backup control file was used. Can also use
-- "alter database open resetlogs" instead.
RMAN> open resetlogs database;
database opened
Several points are worth emphasizing.
1. Recovery using a backup controlfile should be done only if a current control file is
unavailable.
2. All datafiles must be restored from backup. This means the database will need to be
recovered using archived and online redo logs. These MUST be available for recovery
until the time of failure.
3. As with any database recovery involving RESETLOGS, take a fresh backup
immediately.
4. Technically the above is an example of complete recovery - since all committed
transactions were recovered. However, some references consider this to be incomplete
recovery because the database log sequence had to be reset.
After recovery using a backup controlfile, all temporary files associated with locallymanaged tablespaces are no longer available. You can check that this is so by querying
the view V$TEMPFILE - no rows will be returned. Therefore tempfiles must be added (or
recreated) before the database is made available for general use. In the case at hand,
the tempfile already exists so we merely add it to the temporary tablespace. This can
be done using SQLPlus or any tool of your choice:
SQL> alter tablespace temp add tempfile
'D:\oracle_data\datafiles\ORCL\TEMP01.DBF';
Tablespace altered.
SQL>
Check that the file is available by querying v$TEMPFILE.
DATA FILE RECOVERY

Recovery from missing or corrupted datafile(s):
Case 1: Recovery from corrupted or missing datafile
This scenario deals with a situation where a datafile has gone missing, or is corrupted
beyond repair. For concreteness, we look at a case where a datafile is missing. Below is
a transcript of an SQL Plus session that attempts to open a database with a missing
datafile (typed commands in bold, lines in italics are my comments, all other lines are
feedback from SQL Plus):
--open SQL Plus from the command line without
--logging on to database
C:\>sqlplus /nolog
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Jan 25 14:52:41 2005
--Connect to the idle Oracle process as a privileged user and start up instance
SQL> connect / as sysdba
Connected to an idle instance.

SQL> startup
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF'
SQL>
The error message tells us that file# 4 is missing. Note that although the startup
command has failed, the database is in the mount state. Thus, the database control
file, which is also the RMAN repository can be accessed by the instance and by RMAN.
We now recover the missing file using RMAN. The transcript of the recovery session is
reproduced below (bold lines are typed commands, comments in italics, the rest is
feedback from RMAN):
--logon to RMAN
C:\>rman target /
--restore missing datafile

RMAN> restore datafile 4;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=14 devtype=DISK
--recover restored datafile - RMAN applies all logs automatically
RMAN> recover datafile 4;
Starting recover at 26/JAN/05 using channel ORA_DISK_1

C:\ORACLE_ARCHIVE\ORCL\1_5.ARC
--open database for general use
RMAN> alter database open;
database opened
RMAN>
In the above scenario, the database is already in the mount state before the RMAN
session is initiated. If the database is not mounted, you should issue a "startup mount"
command before attempting to restore the missing datafile. The database must be
mounted before any datafile recovery can be done.
If the database is already open when datafile corruption is detected, you can recover
the datafile without shutting down the database. The only additional step is to take the
relevant tablespace offline before starting recovery. In this case you would perform
recovery at the tablespace level. The commands are:
C:\>rman target /
--offline affected tablespace
RMAN> sql 'alter tablespace USERS offline immediate';
sql statement: alter tablespace USERS offline immediate
--recover offlined tablespace
RMAN> recover tablespace USERS;
--online recovered tablespace
RMAN> sql 'alter tablespace USERS online';
sql statement: alter tablespace USERS online
RMAN>
Here we have used the SQL command, which allows us to execute arbitrary SQL from
within RMAN.
Case 2: Recovery from block corruption
It is possible to recover corrupted blocks using RMAN backups. This is a somewhat
exotic scenario, but it can be useful in certain circumstances, as illustrated by the
following example. Here's the situation: a user connected to SQLPlus gets a data block
corruption error when she queries a table. Here's a part of the session transcript:
SQL> connect testuser/testpassword
Connected.
SQL> select count(*) from test_table;
select count(*) from test_table
*
ERROR at line 1:
ORA-01110: data file 4: 'D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF'
Since we know the file and block number, we can perform block level recovery using
RMAN. This is best illustrated by example:
C:\>rman target /
--restore AND recover specific block
RMAN> blockrecover datafile 4 block 2015;
Starting blockrecover at 26/JAN/05
Finished blockrecover at 26/JAN/05
RMAN>
Now our user should be able to query the table from her SQLPlus session. Here's her
session transcript after block recovery.
SQL> select count(*) from test_table;
COUNT(*)
---------217001
SQL>
A couple of important points regarding block recovery:
1. Block recovery can only be done using RMAN.
2. The entire database can be open while performing block recovery.
3. Check all database files for corruption. This is important - there could be other
corrupted blocks. Verification of database files can be done using RMAN or the dbverify
utility. To verify using RMAN simply do a complete database backup with default
settings. If RMAN detects block corruption, it will exit with an error message pointing
out the guilty file/block.
DISASTER RECOVERY
Introduction:
- i.e. a situation in which your database server has been destroyed and has taken all
your database files (control files, logs and data files) with it. Obviously, recovery from a
disaster of this nature is dependent on what you have in terms of backups and
hardware resources. We assume you have the following available after the disaster:
A server with the same disk layout as the original.

The last full hot backup on tape.
With the above items at hand, it is possible to recover all data up to the last full
backup. One can do better if subsequent archive logs (after the last backup) are
available. In our case these aren't available, since our only archive destination was on
the destroyed server ). Oracle provides methods to achieve better data protection. We
will discuss some of these towards the end of the article.
Now on with the task at hand. The high-level steps involved in disaster recovery are:
Build replacement server.

Restore backup from tape.
Install database software.
Create Oracle service.
Restore and recover database.
Step:1 Build the server

You need a server to host the database, so the first step is to acquire or build the new
machine. This is not strictly a DBA task, so we won't delve into details here. The main
point to keep in mind is that the replacement server should, as far as possible, be
identical to the old one. In particular, pay attention to the following areas:
Ideally the server should have the same number of disks as the original. The new disks should
also have enough space to hold all software and data that was on the original server.
The operating system environment should be the same as the original, right up to service pack
and patch level.
The new server must have enough memory to cater to Oracle and operating system / other
software requirements. Oracle memory structures (Shared pool, db buffer caches etc) will be
sized identically to the original database instance. Use of the backup server parameter file will
ensure this.
Step:2 Restore backup from tape

The next step is to get your backup from tape on to disk.
Step:3 Install Oracle Software
The next step is to install Oracle software on the machine. The following points should
be kept in mind when installing the software:
Install the same version of Oracle as was on the destroyed server. The version number should
match right down to the patch level, so this may be a multi-step process involving installation
followed by the application of one or more patch sets and patches.
Do not create a new database at this stage.
Create a listener using the Network Configuration Assistant. Ensure that it has the same name
and listening ports as the original listener. Relevant listener configuration information can be
found in the backed up listener.ora file.
Step:4 Create directory structure for database files

After software installation is completed, create all directories required for datafiles,
(online and archived) logs, control files and backups. All directory paths should match
those on the original server.
Don't worry if you do not know where the database files should be located. You can
obtain the required information from the backup spfile and control file at a later stage.
Continue reading - we'll come back to this later.
Step: 5 Create Oracle service
An Oracle service must be exist before a database is created. The service is created
using the oradim utility, which must be run from the command line. The following
commands show how to create and modify a service (comments in italics, typed
commands in bold):
--create a new service with auto startup
C:\>oradim -new -sid ORCL -intpwd ORCL -startmode a
Unfortunately oradim does not give any feedback, but you can check that the service
exists via the Services administrative panel. The service has been configured to start
automatically when the computer is powered up.
Step: 6 Restore and recover database
Now it is time to get down to the nuts and bolts of database recovery. There are several
steps, so we'll list them in order:
Copy PASSWORD and TNSNAMES file from backup: The backed up password file and
tnsnames.ora files should be copied from the backup directory to the proper locations. Default
location for password and tnsnames files are ORACLE_HOME\database
ORACLE_HOME\network\admin respectively.
Set ORACLE_SID environment variable: ORACLE_SID should be set to the proper SID name
(ORCL in our case). This can be set either in the registry (registry key:
HKLM\Software\Oracle\HOME<X>\ORACLE_SID) or from the system applet in the control panel.
Invoke RMAN and set the DBID: We invoke rman and connect to the target database as usual. No
login credentials are required since we connect from an OS account belonging to ORA_DBA. Note
that RMAN accepts a connection to the database although the database is yet to be recovered.
RMAN doesn't as yet "know" which database we intend to connect to. We therefore need to
identify the (to be restored) database to RMAN. This is done through the database identifier
(DBID). The DBID can be figured out from the name of the controlfile backup. Example: if you
use the controlfile backup format , your controlfile backup name will be something like
"CTL_SP_BAK_C-1507972899-20050228-00". In this case the DBID is 1507972899. Here's a
transcript illustrating the process of setting the DBID:
C:\>rman
RMAN> set dbid 1507972899
executing command: SET DBID
RMAN>connect target /
connected to target database (not started)
RMAN>
Restore spfile from backup:
To restore the spfile, you first need to startup the database in the nomount state. This
starts up the database using a dummy parameter file. After that you can restore the
spfile from the backup (which has been restored from tape ). Finally you restart the
database in nomount state. Here is an example RMAN transcript for the foregoing
procedure. Note the difference in SGA size and components between the two startups:
RMAN> startup nomount
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 'C:\ORACLE\ORA92\DATABASE\INITORCL.ORA'
trying to start the Oracle instance without parameter files ...
Oracle instance started
RMAN> restore spfile from 'e:\backup\CTL_SP_BAK_C-1507972899-2005022800';
Starting restore at 01/MAR/05
channel ORA_DISK_1: autobackup found: e:\backup\CTL_SP_BAK_C-150797289920050228-00
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 01/MAR/05
RMAN> startup force nomount
RMAN>
The instance is now started up with the correct initialization parameters.
We are now in a position to determine the locations of control file and archive
destination, as this information sits in the spfile. This is done via SQL Plus as follows:
C:\>sqlplus /nolog
SQL>connect / as sysdba
SQL> show parameter control_file
SQL> show parameter log_archive_dest
The directories listed in the CONTROL_FILES and LOG_ARCHIVE_DEST_N parameters

should be created at this stage if they haven't been created earlier.
Restore control file from backup: The instance now "knows" where the control files
should be restored, as this is listed in the CONTROL_FILES initialization parameter.
Therefore, the next step is to restore these files from backup. Once the control files are
restored, the instance should be restarted in mount mode. A restart is required because
the instance must read the initialization parameter file in order to determine the control
file locations. At the end of this step RMAN also has its proper configuration
parameters, as these are stored in the control file.
Here is a RMAN session transcript showing the steps detailed here:
RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-150797289920050228-00';
hannel ORA_DISK_1: sid=13 devtype=DISK
channel ORA_DISK_1: restoring controlfile
replicating controlfile
input filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTL
RMAN> shutdown
Oracle instance shut down
RMAN> exit
Recovery Manager complete.
C:\>rman target /
connected to target database (not started)
RMAN>startup mount;
database mounted
RMAN> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
RMAN>
At this stage we can determine the locations of data files and redo logs if we don't
know where they should go. This is done from SQL Plus as follows:
C:\>sqlplus /nolog
SQL>connect / as sysdba
SQL>select name from v$datafile;
SQL>select member from v$logfile;
SQL>
The directories shown in the output should be created manually if this hasn't been done
earlier.
Restore all datafiles: This is easy. Simply issue a "restore database" command from
RMAN, and it will do all the rest for you:
RMAN> restore database;
RMAN>
Recover database:
The final step is to recover the database. Obviously recovery is dependent on the
available archived (and online) redo logs. Since we have lost our database server and
have no remote archive destination, we can recover only up to the time of the backup.
Further, since this is an incomplete recovery, we will have to open the database with
resetlogs. Here's a sample RMAN session illustrating this:
RMAN> recover database;
Starting recover at 01/MAR/05

unable to find archive log archive log thread=1 sequence=1388
RMAN-00569: =ERROR MESSAGE STACK FOLLOWS =
RMAN-06054: media recovery requesting unknown log: thread 1 scn 32230460
RMAN>alter database open resetlogs;
database opened
Restoring an RMAN Backup to Another Node

In certain circumstances, it may be desirable to restore a database from an RMAN
backup onto a machine other than the original host. For example, to recover data at a
given point in time, or to duplicate a production instance.
The example assumes:
The target database is on host A
The database is to be restored onto host B
The directory structure of host B is different to host A
The ORACLE_SID will not change for the restored database
A recovery catalog is being used
The backups were carried out to disk (for illustrative purposes, and to disassociate from
any media manager specific issues)
The following steps are required:
Backup the target on host A
List the datafile locations on host A
Make the backup available to host B
Make a copy of the init.ora available to host B
Edit the init.ora to reflect directory structure changes
Configure SQL*Net connectivity from host to the recovery catalog and duplicated
database
Set up a password file for the duplicated database
Startup nomount the duplicated database
RMAN restore the controlfile(s)
Mount the database
Restore and rename the datafiles
Recover and open the database
Step:1 Backup the Target on Host A
The target database needs to be backed up using RMAN.
The following is one example of RMAN doing an online database backup. In this
example, the backup sets are written to disk.
run {
allocate channel t1 type disk;

backup
tag whole_database_open
format '/oracle/backups/BFS/df_%u'
database;
# switch out of the current logfile
sql 'alter system archive log current';
#backup the archived logs
backup archivelog all
format '/oracle/backups/BFS/al_%u';
# backup a copy of the controlfile that contains records for the
# other backups just made
backup current controlfile tag = cf1 format '/oracle/backups/BFS/cf_%u';
}
Step: 2 List Datafile Locations on Host A
The datafile numbers and location on host A are required. These datafile locations will
change on host B
SQL> select file#, name from v$datafile;
file# name
----- -----------------------------1 /oracle/OFA_base/u01/oradata/V805X/system01.dbf
2 /oracle/OFA_base/u01/oradata/V805X/rbs01.dbf
3 /oracle/OFA_base/u01/oradata/V805X/temp01.dbf
4 /oracle/OFA_base/u01/oradata/V805X/tools01.dbf
The log file names should also be recorded.
SQL> select group#, member from v$logfile;
group# member
----- -----------------------------1 /oracle/OFA_base/u01/oradata/V805X/redo01.log
2 /oracle/OFA_base/u01/oradata/V805X/redo02.log
3 /oracle/OFA_base/u01/oradata/V805X/redo03.log
Step: 3 Make the Backups Available to Host B
Disk Backups
During restore, RMAN will expect the backup sets to be located in the same directory
as written to during the backup.
Tape Backups
The media management software must be configured such that host B is a media
manager client, and can read the backup sets. The media management vendor should
be consulted for support on this issue.
Step: 4 init.ora on host B
The "init.ora" needs to be made available on host B. Any location specific parameters
must be amended. For example, ifile, *_dump_dest, log_archive_dest*, control_files
Step: 5 SQL*Net configuration

If running RMAN from host A:
A. Connectivity to the catalog remains unchanged
B. Configure tnsnames.ora on host A to connect to duplicated db on host B
C. Configure listener.ora on host B to accept connections for duplicated database
If running RMAN from host B:
A Configure tnsnames.ora on host B to connect to catalog listener.ora on catalog host
remains unchanged
B. Configure tnsnames.ora on host B to connect to duplicated db on host B configure
listener.ora on host B to accept connections for duplicated database
If running RMAN from host C (ie, neither host A or host B):
A. Connectivity to the catalog remains unchanged
B. Configure tnsnames.ora on host C to connect to duplicated db on host B configure
listener.ora on host B to accept connections for duplicated database
Step: 6 Setup Password File
In order to allow RMAN remote connections, a password file must be setup for the
duplicated database. For example,
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=kernel
Step: 7 Recover Duplicated Database
Startup nomount the database
SQL> startup nomount pfile=<location of init.ora>
Restore the controlfile(s)

For example,
run{
allocate channel c1 type disk;
restore controlfile;
}
Mount the database
SQL> alter database mount;
Rename and restore the datafiles, and perform database recovery
RMAN can be used to change the location of the datafiles from the location on host A
to the new location on host B.
BLOCK MEDIA RECOVERY WHEN BACKUPS ARE NOT TAKEN

BY MAN.
To Perform Block Media Recovery when there are OS-backups available, but NO RMAN
backups.
Consider that a block corruption is reported in the database and the corruption is not
wide spread.
Since RMAN is not used in the database the initial solution would be to restore the file
from backup and then recover. But this method will require the file should be offline
during the entire process. On the other hand if BMR can be used, the file does not need
to be taken offline.
Step 1 : Identify the backup of the datafilefile which has the corrupted
block(s) and catalog it within RMAN.
Example: Backup is /u01/backup/users01.dbf
$ export ORACLE_SID=orcl
$ RMAN target=/
RMAN> catalog datafilecopy /u01/backup/users01.dbf;
Step 2 : Check the archived redologs.
RMAN is using the archived redologs which are known in V$ARCHIVED_LOG. If the
archivelog files are not reported in V$ARCHIVED_LOG because they are moved to
another location, or aged out of the controlfile, then they need to be cataloged as well.
First verify the existing archived redologs :
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
Then catalog the unknown archived redologs :

RMAN> catalog archivelog /u01/backup/archivelog/Arch_ocl_1_30.dbf
Step 3 : Preform the Block Media Recovery
Having datafile(s) and all required archivelogs cataloged, we can run BMR as follows.
Example for a block recovery of blocks 99, 100, 101 in datafile 5
RMAN> blockrecover datafile 5 block 99,100,101;
Monitoring Recovery Manager Jobs

Sometimes it is useful to identify what a server session performing a backup or copy
operation is doing. You have access to several views that can assist in monitoring the
progress of or obtaining information about RMAN jobs:
View
V$PROCESS
Identifies currently active processes.

V$SESSION
Identifies currently active sessions. Use this view to determine which Oracle database
server sessions correspond to which RMAN allocated channels.
V$SESSION_LONGOPS
Provides progress reports on long-running operations.

V$SESSION_WAIT
Lists the events or resources for which sessions are waiting.

Correlating Server Sessions with Channels
To identify which server sessions correspond to which RMAN channels, use the set
command with the command id parameter. The command id parameter enters the
specified string into the CLIENT_INFO column of the V$SESSION dynamic performance
view. Join V$SESSION with V$PROCESS to correlate the server session with the channel.
To correlate a process with a channel during a backup:
Step:1 Start RMAN and connect to the target database .
Step:2 Set the command id parameter after allocating the channels and then back up
the
desired object.
run {
set command id to 'rman';
backup
incremental level 0
filesperset 5
tablespace 'SYSTEM';
# optionally, issue a host command to access the operating system prompt
host;
sql 'ALTER SYSTEM ARCHIVE LOG ALL';
}
Step:3 Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS
views while the RMAN job is executing.
SELECT sid, spid, client_info FROM v$process p, v$session s WHERE p.addr = s.paddr
AND client_info LIKE '%id=rman%';
SID
8
16
17
18
SPID
21973
22057
22068
22070
CLIENT_INFO
id=rman
id=rman
id=rman,ch=t1
id=rman,ch=t2
Monitoring Job Progress

Each server session performing a backup, restore, or copy reports its progress
compared to the total amount of work required for that particular part of the restore.
For example, if you perform a restore using two channels, and each channel has two
backup sets to restore (a total of 4 sets), then each server session reports its progress
through a single set. When that set is completely restored, RMAN starts reporting
progress on the next set to restore.
Step:1 Start RMAN and connect to the target database and, optionally, the recovery
catalog
database.
Step:2 Start an RMAN job.:

run {
backup database;
}
Step:3 While the job is running, execute a script containing the following SQL
statement:
SELECT sid, serial#, context, sofar, totalwork,round(sofar/totalwork*100,2) "%
Complete"
FROM v$session_longops WHERE opname LIKE 'RMAN%' AND opname NOT LIKE
'%aggregate%'
AND totalwork != 0 AND sofar <> totalwork
/
If you repeat the query while the backup progresses, then you see output such as the
following:
SQL>
SID
8
SQL> /
SID
8
SQL> /
SERIAL#
19
SERIAL#
19
CONTEXT
1
SOFAR
10377
CONTEXT
1
SOFAR
21513
TOTALWORK
36617
% Complete
28.34
TOTALWORK % Complete
36617
58.75
no rows selected
NOTE: If you run the script at intervals of two minutes or more and the % Complete
column does not increase, then RMAN is encountering a problem.
SELECT sid, seconds_in_wait AS sec_wait, event FROM v$session_wait WHERE
wait_time = 0
ORDER BY sid;
SID
1
2
3
4
5
6
7
8
9
12
SEC_WAIT
368383335
1097
387928
0
1408
386114
387626
1060
1060
1060
EVENT
pmon timer
rdbms ipc message
rdbms ipc message
rdbms ipc message
smon timer
rdbms ipc message
rdbms ipc message
SQL*Net message from client
13
2366
14
2757
12 rows selected.

Note: The V$SESSION_WAIT view shows only Oracle events, not media
manager events.
Another Query:
COLUMN
COLUMN
COLUMN
COLUMN
EVENT FORMAT a10

SECONDS_IN_WAIT FORMAT 999
STATE FORMAT a20
CLIENT_INFO FORMAT a30
SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,

sw.STATE, CLIENT_INFO
FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE sw.EVENT LIKE '%disk%'
AND s.SID=sw.SID
AND s.PADDR=p.ADDR
;

RMAN

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RMAN

Caricato da

Copyright:

Formati disponibili

Basic RMAN Tutorial

Making a Full Backup

RMAN> RESTORE DATABASE VALIDATE;

Type of RMAN Backup Tutorial

About Incremental Backups

How Incremental Backups Work

Multilevel Incremental Backups

Differential Incremental Backups

Use Command for incremental Level Backup

select incremental_level, incremental_change#, checkpoint_change#, blocks from

Cumulative Incremental Backups

Use Command for Cumulative Level Backup

belongs to the incarnation of datafile

Incremental Backup Strategy

SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS

RMAN: RESTORE Concept

When Block Media Recovery Should Be Used

RMAN Other Tutorial

The following features are available only with a catalog:

Costs of Using the Recovery Catalog as the RMAN Repository

Back up the recovery catalog metadata

Tablespaces (except for locally-managed temporary tablespaces)

RMAN does not back up the following:

How to Configure RMAN

Connected to target database: ORCL (DBID=1036216947)

Device Type Format:

RMAN> configure controlfile autobackup off;

Complete Steps for Using RMAN through Catalog

RMAN> create catalog tablespace "RMAN";

Recovery Manager: Release 9.2.0.1.0 - Production

RMAN CASE STUDY

Recovery from missing or corrupted redo log group

Case 1: A multiplexed copy of the missing log is available.

using channel ORA_DISK_2

CONTROL FILE RECOVERY

Redo Buffers 667648 bytes

Case 2: All control files lost

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

RMAN> restore database;

Finished recover at 26/JAN/05

DATA FILE RECOVERY

Connected to an idle instance.

--restore missing datafile

archive log thread 1 sequence 4 is already on disk as file

A server with the same disk layout as the original.

Build replacement server.

Step:1 Build the server

Step:2 Restore backup from tape

Step:4 Create directory structure for database files

The directories listed in the CONTROL_FILES and LOG_ARCHIVE_DEST_N parameters

using target database controlfile instead of recovery catalog

starting media recovery

Restoring an RMAN Backup to Another Node

allocate channel t1 type disk;

Step: 5 SQL*Net configuration

Restore the controlfile(s)

BLOCK MEDIA RECOVERY WHEN BACKUPS ARE NOT TAKEN

Then catalog the unknown archived redologs :

Monitoring Recovery Manager Jobs

Identifies currently active processes.

Provides progress reports on long-running operations.

Lists the events or resources for which sessions are waiting.

Monitoring Job Progress