25896654 basic rman tutorial

8/3/2019 25896654 Basic Rman Tutorial

1/42

1 | P a g e

(786)

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 performbackup and recovery. It stores metadata about its operations in the control file of the targetdatabase 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 DBAmanually keeps track of all database files and backups. But RMAN performs these sametasks 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 bebacked up) and RECOVERY CATALOG (Recovery catalog is optional otherwise backupdetails 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 thetarget database and its backup and recovery operations. RMAN stores information about:

Backup sets and piecesImage copies (including archived redo logs)

Proxy copiesThe target database schema


2/42

2 | P a g e

Persistent configuration settings

If you start RMAN without specifying either CATALOG or NOCATALOG on the commandline, then RMAN makes no connection to a repository. If you run a command that requiresthe repository, and if no CONNECT CATALOG command has been issued yet, then RMAN

automatically connects in the default NOCATALOG mode. After that point, the CONNECTCATALOG command is not valid in the session.

Types of Database Connections

You can connect to the following types of databases.

Target databaseRMAN connects you to the target database with the SYSDBA privilege. If you do not havethis privilege, then the connection fails.Recovery catalog database

This database is optional: you can also use RMAN with the default NOCATALOG option.Auxiliary databaseYou can connect to a standby database, duplicate database, or auxiliary instance (standbyinstance or tablespace point-in-time recovery instance

Note: That a SYSDBA privilege is not required when connecting to the recovery catalog. Theonly requirement is that the RECOVERY_CATALOG_OWNER role be granted to theschema owner.

Using Basic RMAN Commands

After you have learned how to connect to a target database, you can immediately beginperforming backup and recovery operations. Use the examples in this section to go through abasic backup and restore scenario using a test database. These examples assume thefollowing:

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 thefollowing: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:


3/42

3 | P a g e

RMAN> REPORT SCHEMA; (RMAN displays the datafiles currently in the targetdatabase.)

Backing Up the Database

In this task, you back up the database to the default disk location. Because you do not specifythe 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 thedatafiles, 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 uponly 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 storagemedium such as tape. You can also back up archived logs to disk. In either case, you candelete the input logs automatically after the backup completes.To back up all archived logsand delete the input logs (from the primary archiving destination only), run the backupcommand 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 asfollows:

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 restoringthem. Run the RESTORE ... VALIDATE command as follows:


4/42

4 | P a g e

RMAN> RESTORE DATABASE VALIDAT;

Type of RMAN Backup Tutorial

Full Backups

A full backup reads the entire file and copies all blocks into the backup set, only skipping datafileblocks that have never been used.

About Incremental Backups

Rman create backup only changed block since a previous backup. You can use RMAN to createincremental 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 atwhich the most recent change was made to the block. During an incremental backup, RMANreads the SCN of each data block in the input file and compares it to the checkpoint SCN of theparent incremental backup. RMAN reads the entire file every time whether or not the blocks havebeen used.

The parent backup is the backup that RMAN uses for comparing the SCNs. If the currentincremental is a differential backup at level n, then the parent is the most recent incremental oflevel n or less. If the current incremental is a cumulative backup at level n, then the parent is themost recent incremental of level n-1 or less. If the SCN in the input data block is greater than orequal 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 aninteger, for example, 0, 1, 2, and so forth. A level 0 incremental backup, which is the base forsubsequent incremental backups, copies all blocks containing data. The only differencebetween 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 alevel 0 backup automatically to serve as the base.

The benefit of performing multilevel incremental backups is that RMAN does notback up all blocks all of the time.

Differential Incremental Backups

HostModoIn a differential level n incremental backup, RMAN backs up all blocks that have changed sincethe most recent backup at level n or lower.

For example, in a differential level 2 backups, RMAN determines which level 2 or level 1 backupoccurred 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 isavailable, RMAN makes a new base level 0 backup for this file.
http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BBdMVlcW5RujiEYaknAPewpXVAdrazSmKrqCmA8WNtwEAEAEg6OyICTgAUNP0x-sFYMsEoAG6voj7A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASZodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9UeXBlLmFzcOABA4ACAakCTZuhuVqVoT7IAoLI9QKoAwPoAzzoA9cC6APLAQ&num=0&adurl=http://www.Hostmodo.com/asp%3Fsid%3DWO_P_Asp%2BWeb%2BHosting&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BBdMVlcW5RujiEYaknAPewpXVAdrazSmKrqCmA8WNtwEAEAEg6OyICTgAUNP0x-sFYMsEoAG6voj7A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASZodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9UeXBlLmFzcOABA4ACAakCTZuhuVqVoT7IAoLI9QKoAwPoAzzoA9cC6APLAQ&num=0&adurl=http://www.Hostmodo.com/asp%3Fsid%3DWO_P_Asp%2BWeb%2BHosting&client=ca-ref-pub-9826402430334234


5/42

5 | P a g e

Case 1: if you want to implement incremental backup strategy as a DBA in your organization:

Use Command for incremental Level Backup

Share photos with friends

RMAN> backup incremental level 0 database tag="SUNDAY";RMAN> backup incremental level 3 database tag="MONDAY";RMAN> backup incremental level 3 database tag="TUESDAY";RMAN> backup incremental level 3 database tag="WEDNESDAY";RMAN> backup incremental level 2 database tag="THURSDAY";RMAN> backup incremental level 3 database tag="FRIDAY";RMAN> backup incremental level 3 database tag="SATURDAY";

Backup Example ( You can view your incremental Backup Details by using followingQuery)


select incremental_level, incremental_change#, checkpoint_change#, blocks fromv$backup_datafile;

Result of above Query:

INC_LEVEL INC_CHANGE# CHECKPOINT_CHANGE# BLOCKS

0 0 271365 59595

3 271365 271369 2

3 271369 271371 1

3 271371 271374 2

2 271365 271378 2

3 271378 271380 1

3 271380 271383 2
http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BfyTElcW5Rs34OpOknAOx0-TUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSgAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEEwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=B4M25lsW5Rqq5KaXKmgOpz9DUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSgAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEFwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BfyTElcW5Rs34OpOknAOx0-TUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSgAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEEwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=B4M25lsW5Rqq5KaXKmgOpz9DUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSgAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEFwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234


6/42

6 | P a g e

Cumulative Incremental Backups


RMAN provides an option to make cumulative incremental backups at level 1 or greater. In acumulative level n backup, RMAN backs up all the blocks used since the most recent backup atlevel n-1 or lower.

For example, in cumulative level 2 backups, RMAN determines which level 1 backup occurredmost 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 onlyneed 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 previousbackups 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#
http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BCZP6l8W5RonZEJPknAOBjdnUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSYAezGnA-gAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEGwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BCZP6l8W5RonZEJPknAOBjdnUAbzS_Cbw7NfHAsWNtwEAEAEg6OyICTgAUNiUzKX______wFgywSYAezGnA-gAcjt6_kDsgERd3d3LmluZGlhbmRiYS5jb226AQhyZWZfdGV4dMgBCNoBJmh0dHA6Ly93d3cuaW5kaWFuZGJhLmNvbS9STUFOX1R5cGUuYXNw4AEGwAIDyAKwkvsCqAMD6APXAugD4AE&num=0&adurl=http://www.flodeo.com/%3Fchange_language%3Den&client=ca-ref-pub-9826402430334234


7/42

7 | P a g e

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 istaken monthly, a cumulative level 1 backup is taken weekly, and a cumulative level 2is taken daily. In this scheme, you never have to apply more than a day's worth ofredo 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 haschanged. If the rate of change to your database is predictable, then you can observethe 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 eachdatafile with at least 50% of its blocks backed up:

SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS,DATAFILE_BLOCKSFROM V$BACKUP_DATAFILEWHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5ORDER BY COMPLETION_TIME;

Compare the number of blocks in differential or cumulative backups to a base level 0backup. For example, if you only create level 1 cumulative backups, then when themost recent level 1 backup is about half of the size of the base level 0 backup, take anew level

RMAN: RESTORE Concept

Use theRMAN RESTOREcommand to restore the following types of files from copies ondisk or backups on other media:

Database (all datafiles) Tablespaces Control files

Archived redo logs Server parameter files

Process of Restore Operations

RMANautomates the procedure for restoring files. When you issue aRESTOREcommand,RMANrestore 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 theSET NEWNAMEcommand

For example:


8/42

8 | P a g e

Ifyou restore datafile 'C:_DATA.DBFto its default location, then RMAN restores the fileC:_DTAA.DBFand overwrites any file that it finds with the same filename.

if you run aSET NEWNAMEcommand before you restore a file, then RMAN creates adatafile 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.DBFnamed 'C:_DATA.DBFandrecords it in the repository. To change the name for datafile 'C:_DATA.DBFto'C:_DATA.DBFin the control file, run a SWITCH command so that RMAN considers therestored 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 notavailable, then RMAN uses metadata from the target database control file. Assuming that youhave 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 thedatabase when performing whole database recovery, or open the database when performingonline 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;


9/42

9 | P a g e

TheRMANrecovery catalog obtains its metadata from the target database control file.RMAN decides which backup sets to restore, and which incremental backups and archivedlogs to use for recovery. A server session on the target database instance performs the actualwork of restore and recovery.

Mechanics of Recovery: Incremental Backups and Redo Logs

RMANdoes 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 fromavailable backups and copies, and then applies incremental backups to the datafiles if it canand if not applies logs.

How RMAN Searches for Archived Redo Logs During Recovery

IfRMANcannot find an incremental backup, then it looks in the repository for the names ofarchived 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 theV$ARCHIVED_LOG view. If the logs were created in multiple destinations or were

generated by the COPY, CATALOG, or RESTORE commands, then multiple, identicalcopies of each log sequence number exist on disk.

If the RMAN repository indicates that a log has been deleted or uncataloged, then RMANceases to consider it as available for recovery. For example, assume that the database archiveslog 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 theDELETE command, then the repository indicates that only /dest2/log100.arc is available forrecovery.

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 themedia recovery. By default, RMAN restores the archived redo logs to the first local archiving


10/42

10 | P a g e

destination specified in the initialization parameter file. You can run the SET ARCHIVELOGDESTINATION command to specify a different restore location. If you specify the DELETEARCHIVELOG option on RECOVER, then RMAN deletes the archived logs after restoringand applying them. If you also specify MAXSIZE integeron the RECOVER command, thenRMAN staggers the restores so that they consume no more than integeramount of disk space

at a time.

Incomplete Recovery

RMAN can perform either complete or incomplete recovery. You can specify a time, SCN, orlog sequence number as a limit for incomplete recovery with the SET UNTIL command orwith an UNTIL clause specified directory on the RESTORE and RECOVER commands.After performing incomplete recovery, you must open the database with the RESETLOGSoption.

Disaster Recovery with a Control File Autobackup

Assume that you lose both the target database and the recovery catalog. All that you haveremaining is a tape with RMAN backups of the target database and archived redo logs. Canyou still recover the database? Yes, assuming that you enabled the control file autobackupfeature. In a disaster recovery situation, RMAN can determine the name of a control fileautobackup even without a repository available. You can then restore this control file, mountthe database, and perform media recovery.

About Block Media Recovery

You can also use theRMAN BLOCKRECOVER command to perform block mediarecovery. Block media recovery recovers an individual corrupt datablock or set of datablockswithin a datafile. In cases when a small number of blocks require media recovery, you canselectively 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*Plusrecovery interface is available.

You can only perform complete recovery of individual blocks. In other words, youcannot stop recovery before all redo has been applied to the block.

You can only recover blocks marked media corrupt. TheV$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a file weremarked corrupt since the most recent BACKUP, BACKUP ... VALIDATE, or COPYcommand 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 errormessage 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:


11/42

11 | P a g e

ORA-01578: ORACLE data block corrupted (file # 7, block # 3)ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'ORA-01578: ORACLE data block corrupted (file # 2, block # 235)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 inaccessiblearchived 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 redochanges for the blocks being recovered.

When RMAN first detects missing or corrupt redo records during block media recovery, itdoes not immediately signal an error because the block undergoing recovery may become anewed blocklater 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,RMANconnects to the target database inNOCATALOGmode, meaning that ituses the control file in the target database as the sole repository ofRMANmetadata. Perhapsthe most important decision you make when usingRMANis whether to create a recoverycatalog as theRMANrepository for normal production operations. A recovery catalog is aschema created in a separate database that contains metadata obtained from the target controlfile.

Benefits of Using the Recovery Catalog as the RMAN Repository

When you use a recovery catalog,RMANcan perform a wider variety of automated backupand 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 theCONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historicalmetadata.

You can report the target database schema at a noncurrent time. You can store RMAN scripts in the recovery catalog.


12/42

12 | P a g e

When restoring and recovering to a time when the database files that exist in thedatabase are different from the files recorded in the mounted control file, the recoverycatalog specifies which files that are needed. Without a catalog, you must first restorea 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, theseconfigurations 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 additionaldatabase.

For example, you have to:Find a database other than the target database to store the recoverycatalog (otherwise, the benefits of maintaining the catalog are lost), or create a new databaseCreate 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 serverparameter

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


13/42

13 | P a g e

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; # defaultCONFIGURE DEFAULT DEVICE TYPE TO DISK; # defaultCONFIGURE 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; #defaultCONFIGURE 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; # defaultCONFIGURE 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 latestand 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 controlfileAND 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 nameinstructs 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.


14/42

14 | P a g e

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 theformat 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 inthe backup set.

Any of the above parameters can be changed using the commands displayed by the "showall" command.For example, one can turn off controlfile autobackups by issuing:

RMAN> configure controlfile autobackup off;

using target database controlfile instead of recovery catalogold RMAN configuration parameters:CONFIGURE CONTROLFILE AUTOBACKUP ON;new RMAN configuration parameters:CONFIGURE CONTROLFILE AUTOBACKUP OFF;new RMAN configuration parameters are successfully stored

RMAN>

Complete Steps for Using RMAN through Catalog

Recovery manager is a platform independent utility for coordinating your backup andrestoration 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;


15/42

15 | P a g e

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

C:>

Register Database

Top Tech-Specific Job Portal - Build your Resume Today

Each database to be backed up by RMAN must be registered:

C:>rman catalog=rman/rman@w2k1 target=sys/password@w2k2\



connected to target database: W2K2 (DBID=1371963417)

connected to recovery catalog database
http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BMS3RaMe5RvTDK5fu-AKOyv2uC_K7yi7a1JDXBMWNtwEAEAEg6OyICTgAUKv_nJcCYMsEoAGCg6b9A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASlodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9DYXRhbG9nLmFzcIACAcACA6gDA-gD1wLoAwU&num=0&adurl=http://www.pinstorm.com/redirect.php%3Fpid%3D176%26url%3Dhttp%253A%252F%252Fwww.cybermediadice.in%26u1%3Dadwords_ppa%26u2%3Dppa_soft_j_loc_link&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BMS3RaMe5RvTDK5fu-AKOyv2uC_K7yi7a1JDXBMWNtwEAEAEg6OyICTgAUKv_nJcCYMsEoAGCg6b9A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASlodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9DYXRhbG9nLmFzcIACAcACA6gDA-gD1wLoAwU&num=0&adurl=http://www.pinstorm.com/redirect.php%3Fpid%3D176%26url%3Dhttp%253A%252F%252Fwww.cybermediadice.in%26u1%3Dadwords_ppa%26u2%3Dppa_soft_j_loc_link&client=ca-ref-pub-9826402430334234


16/42

16 | P a g e

RMAN> register database;

database registered in recovery catalog

starting full resync of recovery catalog

full resync complete

RMAN>

Full Backup

Top Tech-Specific Job Portal - Build your Resume Today

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 thedatabase 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 usingthe follwoing command:

RMAN> resync catalog

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 anexample, where I attempt to startup from SQLPLUS when a redo log is missing:
http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BiaH_ace5RqSQA4X4-gLEpci1C_K7yi7a1JDXBMWNtwEAEAEg6OyICTgAUKv_nJcCYMsEoAGCg6b9A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASlodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9DYXRhbG9nLmFzcOABAoACAcACA6gDA-gD1wLoAwU&num=0&adurl=http://www.pinstorm.com/redirect.php%3Fpid%3D176%26url%3Dhttp%253A%252F%252Fwww.cybermediadice.in%26u1%3Dadwords_ppa%26u2%3Dppa_soft_j_loc_link&client=ca-ref-pub-9826402430334234http://pagead2.googlesyndication.com/pagead/iclk?sa=l&ai=BiaH_ace5RqSQA4X4-gLEpci1C_K7yi7a1JDXBMWNtwEAEAEg6OyICTgAUKv_nJcCYMsEoAGCg6b9A7IBEXd3dy5pbmRpYW5kYmEuY29tugEIcmVmX3RleHTIAQjaASlodHRwOi8vd3d3LmluZGlhbmRiYS5jb20vUk1BTl9DYXRhbG9nLmFzcOABAoACAcACA6gDA-gD1wLoAwU&num=0&adurl=http://www.pinstorm.com/redirect.php%3Fpid%3D176%26url%3Dhttp%253A%252F%252Fwww.cybermediadice.in%26u1%3Dadwords_ppa%26u2%3Dppa_soft_j_loc_link&client=ca-ref-pub-9826402430334234


17/42

17 | P a g e

SQL> startupORACLE instance started.

Total System Global Area 131555128 bytesFixed Size 454456 bytes

Variable Size 88080384 bytesDatabase Buffers 41943040 bytesRedo Buffers 1077248 bytesDatabase mounted.ORA-00313: open failed for members of log group 3 of thread 1ORA-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 abovelocation on D:.

SQL> alter database open;

Database altered.

SQL>

That's it - the database is open for use.

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 fromthe missing log and all subsequent logs. We illustrate using the same example as above. Theerror message indicates that members of log group 3 are missing. We don't have a copy ofthis file, so we know that an incomplete recovery is required. The first step is to determinehow much can be recovered. In order to do this, we query the V$LOG view (when in themount state) to find the system change number (SCN) that we can recover to (Reminder: theSCN 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 lastSCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest SCNthat we can recover to. In order to do the recovery we must first restore ALL datafiles to thisSCN, 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 (typedcommands in bold, comments in italics, all other lines are RMAN feedback):


18/42

18 | P a g e

C:\>rman target /

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database: ORCL (DBID=1507972899)

--Restore ENTIRE database to determined SCN

RMAN> restore database until scn 370254;

Starting restore at 26/JAN/05using channel ORA_DISK_1using channel ORA_DISK_2channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBFrestoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF

channel ORA_DISK_2: starting datafile backupset restorechannel ORA_DISK_2: specifying datafile(s) to restore from backup setrestoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBFrestoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBFchannel ORA_DISK_2: restored backup piece 1

piece handle=E:\BACKUP\13GB14IB_1_1.BAK tag=TAG20050124T171139 params=NULchannel ORA_DISK_2: restore completechannel ORA_DISK_1: restored backup piece 1

piece handle=E:\BACKUP\14GB14IB_1_1.BAK tag=TAG20050124T171139 params=NULchannel ORA_DISK_1: restore completeFinished restore at 26/JAN/05

--Recover database

RMAN> recover database until scn 370254;

Starting recover at 26/JAN/05using channel ORA_DISK_1using channel ORA_DISK_2

starting media recovery

archive log thread 1 sequence 9 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_9.ARCarchive log thread 1 sequence 10 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_10.ARCarchive log thread 1 sequence 11 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_11.ARCarchive log thread 1 sequence 12 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_12.ARCarchive log filename=E:\ORACLE_ARCHIVE\ORCL\1_9.ARC thread=1 sequence=9archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_10.ARC thread=1 sequence=10

media recovery completeFinished recover at 26/JAN/05


19/42

19 | P a g e

--open database with RESETLOGS (see comments below)

RMAN> alter database open resetlogs;

database openedRMAN>

The following points should be noted:

1. The entire database must be restored to the SCN that has been determined by queryingv$log.

2. All changes beyond that SCN are lost. This method of recovery should be used only if youare 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 theRESETLOGS option must be used for any incomplete 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 onlinelogs are located. Oracle expects to find control files at locations specified in theCONTROL_FILE initialisation parameter. The instance will fail to mount the database if anyone of the control files are missing or corrupt. Here's an example:

SQL> startup

ORACLE instance started.

Total System Global Area 135338868 bytesFixed Size 453492 bytesVariable Size 109051904 bytesDatabase Buffers 25165824 bytesRedo Buffers 667648 bytesORA-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


20/42

20 | P a g e

OSD-04012: file size mismatch (OS 5447783)

The above corruption was introduced by manually editing the control file when the databasewas closed.

The solution is simple, provided you have at least one uncorrupted control file - replace thecorrupted control file with a copy using operating system commands. Remember to renamethe 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 backupcontrol file. The recovery needs to be performed from within RMAN, and requires that alllogs (archived and current online logs) since the last backup are available. The logs arerequired because all datafiles must also be restored from backup. The database will then haveto 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 linesare RMAN feedback):

-- Connect to RMAN

C:\rman

Recovery Manager: Release 9.0.1.1.1 - Production(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 autobackupname isCTL_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)

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database: ORCL (not mounted)

RMAN> restore controlfile from autobackup;

Starting restore at 26/JAN/05using channel ORA_DISK_1channel ORA_DISK_1: restoring controlfile

channel ORA_DISK_1: restore completereplicating controlfile


21/42

21 | P a g e

input filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTLoutput filename=E:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL02.CTLoutput filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTLFinished restore at 26/JAN/05

-- 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;

Starting restore at 26/JAN/05using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBFrestoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBFchannel ORA_DISK_1: restored backup piece 1

piece handle=E:\BACKUP\0DGB0I79_1_1.BAK tag=TAG20050124T115832params=NULL

channel ORA_DISK_1: restore completechannel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBFrestoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBFchannel ORA_DISK_1: restored backup piece 1

piece handle=E:\BACKUP\0CGB0I78_1_1.BAK tag=TAG20050124T115832params=NULLchannel ORA_DISK_1: restore completeFinished restore at 26/JAN/05

--Database must be recovered because all datafiles have been restored from

-- backup

RMAN> recover database;

Starting recover at 26/JAN/05using channel ORA_DISK_1starting media recoveryarchive log thread 1 sequence 2 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_2.ARC

archive log thread 1 sequence 4 is already on disk as fileD:\ORACLE_DATA\LOGS\ORCL\REDO02A.LOG


22/42

22 | P a g e

archive log thread 1 sequence 5 is already on disk as fileD:\ORACLE_DATA\LOGS\ORCL\REDO01A.LOGarchive log thread 1 sequence 6 is already on disk as fileD:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOGarchive log filename=E:\ORACLE_ARCHIVE\ORCL\1_2.ARC thread=1 sequence=2

archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_3.ARC thread=1 sequence=3archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO02A.LOG thread=1sequence=4archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO01A.LOG thread=1sequence=5archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG thread=1sequence=6media recovery completeFinished recover at 26/JAN/05

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

2. All datafiles must be restored from backup. This means the database will need to berecovered using archived and online redo logs. These MUST be available for recovery untilthe 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 incompleterecovery because the database log sequence had to be reset.

After recovery using a backup controlfile, all temporary files associated with locally-managed tablespaces are no longer available. You can check that this is so by querying theview V$TEMPFILE - no rows will be returned. Therefore tempfiles must be added (orrecreated) before the database is made available for general use. In the case at hand, thetempfile already exists so we merely add it to the temporary tablespace. This can be doneusing SQLPlus or any tool of your choice:

SQL> alter tablespace temp add tempfile

'D:\oracle_data\datafiles\ORCL\TEMP01.DBF';


23/42

23 | P a g e

Tablespace altered.

SQL>

Check that the file is available by querying v$TEMPFILE

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 beyondrepair. For concreteness, we look at a case where a datafile is missing. Below is a transcriptof an SQL Plus session that attempts to open a database with a missing datafile (typedcommands in bold, lines in italics are my comments, all other lines are feedback from SQLPlus):

--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 2005Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.--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

ORACLE instance started.Total System Global Area 131555128 bytesFixed Size 454456 bytesVariable Size 88080384 bytesDatabase Buffers 41943040 bytes

Redo Buffers 1077248 bytesDatabase mounted.ORA-01157: cannot identify/lock data file 4 - see DBWR trace fileORA-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 hasfailed, the database is in the mount state. Thus, the database control file, which is also theRMAN 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 (boldlines are typed commands, comments in italics, the rest is feedback from RMAN):


24/42

24 | P a g e

--logon to RMAN

C:\>rman target /


Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database: ORCL (DBID=1507972899)--restore missing datafile

RMAN> restore datafile 4;Starting restore at 26/JAN/05using target database controlfile instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=14 devtype=DISKallocated channel: ORA_DISK_2

channel ORA_DISK_2: sid=15 devtype=DISKchannel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBFchannel ORA_DISK_1: restored backup piece 1

piece handle=D:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708params=NULLchannel ORA_DISK_1: restore completeFinished restore at 26/JAN/05

--recover restored datafile - RMAN applies all logs automatically

RMAN> recover datafile 4;

Starting recover at 26/JAN/05 using channel ORA_DISK_1using channel ORA_DISK_2starting media recoveryarchive log thread 1 sequence 4 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_4.ARCarchive log thread 1 sequence 5 is already on disk as fileC:\ORACLE_ARCHIVE\ORCL\1_5.ARC

archive log thread 1 sequence 6 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_6.ARCarchive log thread 1 sequence 7 is already on disk as fileE:\ORACLE_ARCHIVE\ORCL\1_7.ARCarchive log filename=E:\ORACLE_ARCHIVE\ORCL\1_4.ARC thread=1 sequence=4archive log filename=C:\ORACLE_ARCHIVE\ORCL\1_5.ARC thread=1 sequence=5media recovery completeFinished recover at 26/JAN/05

--open database for general use

RMAN> alter database open;


25/42

25 | P a g e

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 beforeattempting to restore the missing datafile. The database must be mounted before any datafilerecovery can be done.

If the database is already open when datafile corruption is detected, you can recover thedatafile without shutting down the database. The only additional step is to take the relevanttablespace offline before starting recovery. In this case you would perform recovery at thetablespace level. The commands are:

C:\>rman target /

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database: ORCL (DBID=1507972899)

--offline affected tablespace

RMAN> sql 'alter tablespace USERS offline immediate';

using target database controlfile instead of recovery catalogsql statement: alter tablespace USERS offline immediate

--recover offlined tablespace

RMAN> recover tablespace USERS;

Starting recover at 26/JAN/05allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=14 devtype=DISKallocated channel: ORA_DISK_2channel ORA_DISK_2: sid=12 devtype=DISKstarting media recovery

media recovery completeFinished recover at 26/JAN/05

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


26/42

26 | P a g e

Case 2: Recovery from block corruption

It is possible to recover corrupted blocks using RMAN backups. This is a somewhat exoticscenario, but it can be useful in certain circumstances, as illustrated by the followingexample. 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-01578: ORACLE data block corrupted (file # 4, block # 2015)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 usingRMAN. This is best illustrated by example:

C:\>rman target /

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: ORCL (DBID=1507972899)

--restore AND recover specific block

RMAN> blockrecover datafile 4 block 2015;

Starting blockrecover at 26/JAN/05using target database controlfile instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=19 devtype=DISKallocated channel: ORA_DISK_2

channel ORA_DISK_2: sid=20 devtype=DISKchannel ORA_DISK_1: restoring block(s)channel ORA_DISK_1: specifying block(s) to restore from backup setrestoring blocks of datafile 00004channel ORA_DISK_1: restored block(s) from backup piece 1

piece handle=E:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708params=NULLchannel ORA_DISK_1: block restore completestarting media recoverymedia recovery completeFinished blockrecover at 26/JAN/05

RMAN>


27/42

27 | P a g e

Now our user should be able to query the table from her SQLPlus session. Here's her sessiontranscript 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 corruptedblocks. Verification of database files can be done using RMAN or the dbverify utility. Toverify using RMAN simply do a complete database backup with default settings. If RMANdetects 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 yourdatabase 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. Weassume 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. Onecan do better if subsequent archive logs (after the last backup) are available. In our case thesearen'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 towardsthe 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 newmachine. This is not strictly a DBA task, so we won't delve into details here. The main point


28/42

28 | P a g e

to keep in mind is that the replacement server should, as far as possible, be identical to the oldone. In particular, pay attention to the following areas:

Ideally the server should have the same number of disks as the original. The newdisks 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 cachesetc) will be sized identically to the original database instance. Use of the backupserver 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 bekept in mind when installing the software:

Install the same version of Oracle as was on the destroyed server. The version numbershould match right down to the patch level, so this may be a multi-step processinvolving 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 configurationinformation 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, (onlineand archived) logs, control files and backups. All directory paths should match those on theoriginal server.

Don't worry if you do not know where the database files should be located. You can obtainthe required information from the backup spfile and control file at a later stage. Continuereading - 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 theoradim utility, which must be run from the command line. The following commands showhow 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


29/42

29 | P a g e

Unfortunately oradim does not give any feedback, but you can check that the service existsvia the Services administrative panel. The service has been configured to start automaticallywhen 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:

CopyPASSWORD and TNSNAMESfile from backup: The backed up password fileand tnsnames.ora files should be copied from the backup directory to the properlocations. Default location for password and tnsnames files areORACLE_HOME\database ORACLE_HOME\network\admin respectively.

Set ORACLE_SID environment variable: ORACLE_SID should be set to the properSID name (ORCL in our case). This can be set either in the registry (registry key:HKLM\Software\Oracle\HOME\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 accountbelonging to ORA_DBA. Note that RMAN accepts a connection to the databasealthough the database is yet to be recovered. RMAN doesn't as yet "know" whichdatabase 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 DBIDcan be figured out from the name of the controlfile backup. Example: if you use thecontrolfile backup format , your controlfile backup name will be something like"CTL_SP_BAK_C-1507972899-20050228-00". In this case the DBID is1507972899. Here's a transcript illustrating the process of setting the DBID:

C:\>rman

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

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 thenomount state. This starts up the database using a dummy parameter file. After that you canrestore the spfile from the backup (which has been restored from tape ). Finally you restartthe 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


30/42

30 | P a g e

startup failed: ORA-01078: failure in processing system parametersLRM-00109: could not open parameter file'C:\ORACLE\ORA92\DATABASE\INITORCL.ORA'trying to start the Oracle instance without parameter files ...Oracle instance started

Total System Global Area 97590928 bytes

Fixed Size 454288 bytesVariable Size 46137344 bytesDatabase Buffers 50331648 bytesRedo Buffers 667648 bytes

RMAN> restore spfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00';

Starting restore at 01/MAR/05

using target database controlfile instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=9 devtype=DISKchannel ORA_DISK_1: autobackup found: e:\backup\CTL_SP_BAK_C-1507972899-20050228-00channel ORA_DISK_1: SPFILE restore from autobackup completeFinished restore at 01/MAR/05

RMAN> startup force nomount

Oracle instance started


Fixed Size 457456 bytesVariable Size 763363328 bytesDatabase Buffers 754974720 bytesRedo Buffers 2142208 bytes

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, asthis information sits in the spfile. This is done via SQL Plus as follows:

C:\>sqlplus /nolog

SQL>connect / as sysdba

Connected.

SQL> show parameter control_file

SQL> show parameter log_archive_dest


31/42

31 | P a g e

The directories listed in the CONTROL_FILESandLOG_ARCHIVE_DEST_Nparametersshould 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 shouldbe restored, as this is listed in the CONTROL_FILESinitialization parameter. Therefore, the

next step is to restore these files from backup. Once the control files are restored, the instanceshould be restarted in mount mode. A restart is required because the instance must read theinitialization parameter file in order to determine the control file locations. At the end of thisstep RMAN also has its proper configuration parameters, as these are stored in the controlfile.

Here is a RMAN session transcript showing the steps detailed here:

RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00';


allocated channel: ORA_DISK_1hannel ORA_DISK_1: sid=13 devtype=DISKchannel ORA_DISK_1: restoring controlfilechannel ORA_DISK_1: restore completereplicating controlfileinput filename=D:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL01.CTLoutput filename=E:\ORACLE_DATA\CONTROLFILE\ORCL\CONTROL02.CTLoutput filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTLFinished restore at 01/MAR/05

RMAN> shutdown

Oracle instance shut down

RMAN> exit

Recovery Manager complete.

C:\>rman target /

Recovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.connected to target database (not started)

RMAN>startup mount;

Oracle instance starteddatabase mounted


Fixed Size 457456 bytesVariable Size 763363328 bytes


32/42

32 | P a g e

Database Buffers 754974720 bytesRedo Buffers 2142208 bytes

RMAN> show all;

using target database controlfile instead of recovery catalogRMAN configuration parameters are:CONFIGURE RETENTION POLICY TO REDUNDANCY 2;CONFIGURE BACKUP OPTIMIZATION OFF; # defaultCONFIGURE DEFAULT DEVICE TYPE TO DISK; # defaultCONFIGURE 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; # defaultCONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; #

defaultCONFIGURE 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; # defaultCONFIGURE SNAPSHOT CONTROLFILE NAME TO'C:\ORACLE\ORA92\DATABASE\SNCFORCL.ORA'; # default

RMAN>

At this stage we can determine the locations of data files and redo logs if we don't knowwhere they should go. This is done from SQL Plus as follows:

C:\>sqlplus /nolog

SQL>connect / as sysdba

Connected.

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

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;


using target database controlfile instead of recovery catalog


33/42

33 | P a g e

allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=11 devtype=DISKallocated channel: ORA_DISK_2channel ORA_DISK_2: sid=8 devtype=DISKchannel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBFrestoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBFrestoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS02.DBFchannel ORA_DISK_2: starting datafile backupset restorechannel ORA_DISK_2: specifying datafile(s) to restore from backup setrestoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBFrestoring datafile 00005 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBFrestoring datafile 00006 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS02.DBFchannel ORA_DISK_2: restored backup piece 1

piece handle=E:\BACKUP\80G6E1TT_1_1.BAK tag=TAG20041130T222501

params=NULLchannel ORA_DISK_1: restored backup piece 1

piece handle=E:\BACKUP\81G6E1TU_1_1.BAK tag=TAG20041130T222501params=NULLchannel ORA_DISK_2: restored backup piece 2

piece handle=E:\BACKUP\80G6E1TT_2_1.BAK tag=TAG20041130T222501params=NULLchannel ORA_DISK_1: restored backup piece 2

piece handle=E:\BACKUP\81G6E1TU_2_1.BAK tag=TAG20041130T222501params=NULLchannel ORA_DISK_1: restored backup piece 3

piece handle=E:\BACKUP\81G6E1TU_3_1.BAK tag=TAG20041130T222501params=NULLchannel ORA_DISK_1: restore completechannel ORA_DISK_2: restored backup piece 3

piece handle=E:\BACKUP\80G6E1TT_3_1.BAK tag=TAG20041130T222501params=NULLchannel ORA_DISK_2: restore completeFinished restore at 01/MAR/05

RMAN>

Recover database: The final step is to recover the database. Obviously recovery is dependenton the available archived (and online) redo logs. Since we have lost our database server andhave 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 withresetlogs. Here's a sample RMAN session illustrating this:

RMAN> recover database;

Starting recover at 01/MAR/05using channel ORA_DISK_1

using channel ORA_DISK_2


34/42

34 | P a g e

starting media recovery

unable to find archive log archive log thread=1 sequence=1388

RMAN-00571: ==============================

RMAN-00569: =ERROR MESSAGE STACK FOLLOWS =RMAN-00571: ===============================RMAN-03002: failure of recover command at 04/01/2005 14:14:43RMAN-06054: media recovery requesting unknown log: thread 1 scn 32230460

RMAN>alter database open resetlogs;

database opened

RMAN>

Note that RMAN automatically applies all available archive logs. It first applies the backedup log and then searches for subsequent logs in the archive destination. This opens the doorfor further recovery if the necessary logs are available. In our case, however, we have nomore redo so we open the database with resetlogs. The error message above simply indicatesthat RMAN has searched, unsuccessfully, for subsequent logs.

That's it. The database has been recovered, from scratch, to the last available backup. Nowhaving done this, it is worth spending some time in discussing how one can do better - i.e.recover up to a point beyond the backup. We do this in the next section.

Restoring an RMAN Backup to Another Node

In certain circumstances, it may be desirable to restore a database from anRMANbackup onto a machine other than the original host. For example, to recover data at a givenpoint in time, or to duplicate a production instance.

The example assumes:

The target database is on host AThe database is to be restored onto host BThe directory structure of host B is different to host A

The ORACLE_SID will not change for the restored databaseA recovery catalog is being usedThe backups were carried out to disk (for illustrative purposes, and to disassociate from anymedia manager specific issues)

The following steps are required:

Backup the target on host AList the datafile locations on host AMake the backup available to host BMake a copy of the init.ora available to host B

Edit the init.ora to reflect directory structure changesConfigure SQL*Net connectivity from host to the recovery catalog and duplicated database


35/42

35 | P a g e

Set up a password file for the duplicated databaseStartup nomount the duplicated databaseRMAN restore the controlfile(s)Mount the databaseRestore 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 thisexample, the backup sets are written to disk.

run {allocate channel t1 type disk;

backup

tag whole_database_openformat '/oracle/backups/BFS/df_%u'database;# switch out of the current logfilesql 'alter system archive log current';#backup the archived logs

backup archivelog allformat '/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 willchange on host B

SQL> select file#, name from v$datafile;

file# name----- ------------------------------1 /oracle/OFA_base/u01/oradata/V805X/system01.dbf2 /oracle/OFA_base/u01/oradata/V805X/rbs01.dbf3 /oracle/OFA_base/u01/oradata/V805X/temp01.dbf4 /oracle/OFA_base/u01/oradata/V805X/tools01.dbf5 /oracle/OFA_base/u01/oradata/V805X/users01.dbf6 /oracle/OFA_base/u01/oradata/V805X/users02.dbf7 /oracle/OFA_base/u01/oradata/V805X/rbs02.dbf8 /oracle/OFA_base/u01/oradata/V805X/rcvcat.dbf

The log file names should also be recorded.


36/42

36 | P a g e

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.log3 /oracle/OFA_base/u01/oradata/V805X/redo03.log

Step: 3 Make the Backups Available to Host B

Obeus.com -Pay Per Click Advertising,Pay Per Click Affiliate Program,Free TrafficCounters. More information aboutindiandba

Disk Backups

During restore,RMANwill 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 managerclient, and can read the backup sets. The media management vendor should be consulted forsupport 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 mustbe amended. For example, ifile, *_dump_dest, log_archive_dest*, control_files

Step: 5 SQL*Net configuration

Obeus.com -Pay Per Click Advertising,Pay Per Click Affiliate Program,Free Traffic

Counters. More information aboutindiandba

If running RMAN from host A:

A. Connectivity to the catalog remains unchangedB. Configure tnsnames.ora on host A to connect to duplicated db on host BC. 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 remainsunchangedB. 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
http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/


37/42

37 | P a g e

If running RMAN from host C (ie, neither host A or host B):

A. Connectivity to the catalog remains unchangedB. Configure tnsnames.ora on host C to connect to duplicated db on host B configurelistener.ora on host B to accept connections for duplicated database

Step: 6 Setup Password File

Obeus.com -Pay Per Click Advertising,Pay Per Click Affiliate Program,Free Traffic

Counters. More information aboutindiandba

In order to allow RMAN remote connections, a password file must be setup for the duplicateddatabase. 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=

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 thenew location on host B.

For example,run {

allocate channel c1 type disk;allocate channel c2 type disk;

allocate channel c3 type disk;
http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/http://obeus.com/http://obeus.com/pay-per-click-advertising/http://obeus.com/affiliate-program/http://obeus.com/traffic-counter/http://obeus.com/traffic-counter/http://redirect.alexa.com/redirect?obeus.comhttp://obeus.com/site_info/7547/


38/42

38 | P a g e

set newname for datafile 1 to '/oracle/datafiles/system01.dbf';set newname for datafile 2 to '/oracle/datafiles/rbs01.dbf';set newname for datafile 3 to '/oracle/datafiles/temp01.dbf';set newname for datafile 4 to '/oracle/datafiles/tools01.dbf';set newname for datafile 5 to '/oracle/datafiles/users01.dbf';

set newname for datafile 6 to '/oracle/datafiles/users02.dbf';set newname for datafile 7 to '/oracle/datafiles/rbs02.dbf';set newname for datafile 8 to '/oracle/datafiles/rcvcat.dbf';

restore database;

switch datafile all;}

Recover and open the database

HOW TO PERFORM BLOCK MEDIA RECOVERY WHEN BACKUPS ARE NOT

TAKEN BY RMAN.

To Perform Block Media Recovery when there are OS-backups available, but NO RMANbackups.

Consider that a block corruption is reported in the database and the corruption is not widespread.

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 theentire process. On the other hand if BMR can be used, the file does not need to be takenoffline.

Step 1 : Identify the backup of the datafilefile which has the corrupted block(s) and catalogit 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 thearchivelog files are not reported in V$ARCHIVED_LOG because they are moved to anotherlocation, 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;


39/42

39 | P a g e

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 copyoperation is doing. You have access to several views that can assist in monitoring the

progress of or obtaining information aboutRMANjobs:

View

V$PROCESS

Identifies currently active processes.V$SESSIONIdentifies currently active sessions. Use this view to determine which Oracle database serversessions correspond to which RMAN allocated channels.

V$SESSION_LONGOPSProvides progress reports on long-running operations.

V$SESSION_WAITLists 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 setcommand with the command id parameter. The command id parameter enters the specifiedstring into the CLIENT_INFO column of the V$SESSION dynamic performance view. JoinV$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 thedesired object.run {allocate channel t1 type disk;allocate channel t2 type disk;set command id to 'rman';

backup

incremental level 0filesperset 5


40/42

40 | P a g e

tablespace 'SYSTEM';# optionally, issue a host command to access the operating system prompthost;sql 'ALTER SYSTEM ARCHIVE LOG ALL';}

Step:3 Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESSviews while the RMAN job is executing.

SELECT sid, spid, client_infoFROM v$process p, v$session sWHERE p.addr = s.paddrAND client_info LIKE '%id=rman%';

SID SPID CLIENT_INFO8 21973 id=rman

16 22057 id=rman17 22068 id=rman,ch=t118 22070 id=rman,ch=t2

Monitoring Job Progress

Each server session performing a backup, restore, or copy reports its progress compared tothe 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 backupsets to restore (a total of 4 sets), then each server session reports its progress through a singleset. When that set is completely restored, RMAN starts reporting progress on the next set torestore.

Step:1 Start RMAN and connect to the target database and, optionally, the recovery catalogdatabase.

Step:2 Start an RMAN job.:run {allocate channel t1 type disk;

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_longopsWHERE opname LIKE 'RMAN%'AND opname NOT LIKE '%aggregate%'AND totalwork != 0AND sofar totalwork/

If you repeat the query while the backup progresses, then you see output such as the

following:


41/42

41 | P a g e

SQL>SID SERIAL# CONTEXT SOFAR TOTALWORK % Complete8 19 1 10377 36617 28.34

SQL> /

SID SERIAL# CONTEXT SOFAR TOTALWORK % Complete8 19 1 21513 36617 58.75

SQL> /

SQL> /no rows selected

NOTE: If you run the script at intervals of two minutes or more and the % Complete columndoes not increase, then RMAN is encountering a problem.

SELECT sid, seconds_in_wait AS sec_wait, event FROM v$session_wait WHEREwait_time = 0ORDER BY sid;

SID SEC_WAIT EVENT1 368383335 pmon timer2 1097 rdbms ipc message3 387928 rdbms ipc message4 0 rdbms ipc message5 1408 smon timer6 386114 rdbms ipc message7 387626 rdbms ipc message8 1060 SQL*Net message from client9 1060 SQL*Net message from client12 1060 SQL*Net message from client13 2366 SQL*Net message from client14 2757 SQL*Net message from client12 rows selected.

Note: The V$SESSION_WAIT view shows only Oracle events, not media manager events.

Another Query:

COLUMN EVENT FORMAT a10COLUMN SECONDS_IN_WAIT FORMAT 999COLUMN STATE FORMAT a20COLUMN CLIENT_INFO FORMAT a30

SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT,sw.STATE, CLIENT_INFOFROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS pWHERE sw.EVENT LIKE '%disk%'

AND s.SID=sw.SIDAND s.PADDR=p.ADDR


42/42

42 | P a g e

================================================

================================================

===========================

25896654 basic rman tutorial

Documents