RMAN Tutorial p

31 | Page

Basic RMAN Tutorial

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 methodsRMAN is Oracle's backup and recovery utility. With RMAN, backups become as easy as:BACKUP DATABASE;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 ProceduresBy 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 ArchitectureAn 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 RepositoryThe 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 piecesImage copies (including archived redo logs)Proxy copiesThe target database schemaPersistent configuration settingsIf 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 ConnectionsYou 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 instanceNote: 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 CommandsAfter 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 Databaserman TARGET /If the database is already mounted or open, then RMAN displays output similar to the following:Recovery Manager: Release 9.2.0.0.0connected to target database: RMAN (DBID=1237603294)Reporting the Current Schema of the Target DatabaseIn 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 DatabaseIn 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 BackupRun 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 BackupIncremental 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 LogsTypically, 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 CopiesTo 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 BackupCheck 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 VALIDAT;

Type of RMAN Backup Tutorial

Full BackupsA 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 BackupsRman 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 BackupsRMAN 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

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

For example, in a differential level 2 backups, RMAN determines which level 2 or level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. If no level 0 backup is available, RMAN makes a new base level 0 backup for this file.

Case 1: if you want to implement incremental backup strategy as a DBA in your organization: Use Command for incremental Level Backup

RMAN> backup incremental level 0 database tag="SUNDAY";

RMAN> backup incremental level 3 database tag="MONDAY";

RMAN> backup incremental level 3 database tag="TUESDAY";

RMAN> backup incremental level 3 database tag="WEDNESDAY";

RMAN> backup incremental level 2 database tag="THURSDAY";

RMAN> backup incremental level 3 database tag="FRIDAY";

RMAN> backup incremental level 3 database tag="SATURDAY";

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

select incremental_level, incremental_change#, checkpoint_change#, blocks from v$backup_datafile;

Result of above Query:

INC_LEVEL INC_CHANGE# CHECKPOINT_CHANGE# BLOCKS

0 0 271365 59595

3 271365 271369 2

3 271369 271371 1

3 271371 271374 2

2 271365 271378 2

3 271378 271380 1

3 271380 271383 2

Cumulative Incremental Backups

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

For example, in cumulative level 2 backups, RMAN determines which level 1 backup occurred most recently and copies all blocks changed since that backup. If no level 1 backups is available, RMAN copies all blocks changed since the base level 0 backup.

Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.

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

Use Command for Cumulative Level Backup

backup incremental level=0 database tag='base';

backup incremental level=2 cumulative database tag='monday';

backup incremental level=2 cumulative database tag='tuesday';

backup incremental level=2 cumulative database tag='wednesday';

backup incremental level=2 cumulative database tag='thursday';

backup incremental level=2 cumulative database tag='friday';

backup incremental level=2 cumulative database tag='saturday';

backup incremental level=1 cumulative database tag='weekly';

Incremental backup implementation

RMAN will determine the incremental SCN for each datafile

Find the backup with highest checkpoint scn that

belongs to the incarnation of datafile

matches the given file#

is an incremental backup/copy at level N or less if noncumulative or

is an incremental backup/copy at level N-1 or less if cumulative

belongs to an available backup set if backup

Incremental Backup StrategyYou 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_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 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

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_passwordRecovery Manager: Release 9.2.0.1.0 - ProductionCopyright (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; # 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'; #defaultRMAN>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 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 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 catalogold RMAN configuration parameters:CONFIGURE CONTROLFILE AUTOBACKUP ON;new RMAN configuration parameters:CONFIGURE CONTROLFILE AUTOBACKUP OFF;new RMAN configuration parameters are successfully storedRMAN>

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

Recovery Manager: Release 9.2.0.1.0 - Production

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

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

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

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

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> startupORACLE instance started.Total System Global Area 131555128 bytesFixed Size 454456 bytesVariable 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 above location 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 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 accessSQL> select first_change# from v$log whnhi.ere group#=3 ;FIRST_CHANGE#-------------370255SQL>

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 /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 SCNRMAN> 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.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 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBFchannel ORA_DISK_2: restored backup piece 1piece handle=E:\BACKUP\13GB14IB_1_1.BAK tag=TAG20050124T171139 params=NULchannel ORA_DISK_2: restore completechannel ORA_DISK_1: restored backup piece 1piece handle=E:\BACKUP\14GB14IB_1_1.BAK tag=TAG20050124T171139 params=NULchannel ORA_DISK_1: restore completeFinished restore at 26/JAN/05--Recover databaseRMAN> recover database until scn 370254;Starting recover at 26/JAN/05using channel ORA_DISK_1using channel ORA_DISK_2starting media recoveryarchive log thread 1 sequence 9 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_9.ARCarchive log thread 1 sequence 10 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_10.ARCarchive log thread 1 sequence 11 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_11.ARCarchive log thread 1 sequence 12 is already on disk as file E:\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=10media recovery completeFinished recover at 26/JAN/05--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 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.

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

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

ORACLE instance started.

Total System Global Area 135338868 bytes

Fixed Size 453492 bytes

Variable Size 109051904 bytes

Database Buffers 25165824 bytes

Redo Buffers 667648 bytes

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

Recovery Manager: Release 9.0.1.1.1 - Production(c) Copyright 2001 Oracle Corporation. All rights reserved.

RMAN> set dbid 4102753520executing 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_installconnected to target database: (not mounted)



connected to target database: ORCL (not mounted)

RMAN> restore controlfile from autobackup;

Starting restore at 26/JAN/05

using channel ORA_DISK_1

channel ORA_DISK_1: restoring controlfile

channel ORA_DISK_1: restore complete

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

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



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

channel ORA_DISK_1: restored backup piece 1

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




restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF

restoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF


piece handle=E:\BACKUP\0CGB0I78_1_1.BAK tag=TAG20050124T115832 params=NULL



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

-- backup

RMAN> recover database;

Starting recover at 26/JAN/05


starting media recovery

archive log thread 1 sequence 2 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_2.ARC

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



archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_2.ARC thread=1 sequence=2


archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO02A.LOG thread=1 sequence=4



media recovery complete

Finished 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 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 locally-managed 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

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

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



connected to target database: ORCL (DBID=1507972899)

--restore missing datafile

RMAN> restore datafile 4;


using target database controlfile instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=14 devtype=DISK





restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF


piece handle=D:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708 params=NULL



--recover restored datafile - RMAN applies all logs automatically

RMAN> recover datafile 4;

Starting recover at 26/JAN/05 using channel ORA_DISK_1




archive log thread 1 sequence 5 is already on disk as file C:\ORACLE_ARCHIVE\ORCL\1_5.ARC




archive log filename=C:\ORACLE_ARCHIVE\ORCL\1_5.ARC thread=1 sequence=5



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

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






channel ORA_DISK_1: restoring block(s)

channel ORA_DISK_1: specifying block(s) to restore from backup set

restoring blocks of datafile 00004

channel ORA_DISK_1: restored block(s) from backup piece 1

piece handle=E:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708 params=NULL

channel ORA_DISK_1: block restore complete



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 serverYou 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 startupC:\>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 databaseNow 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\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:\>rmanRecovery Manager: Release 9.2.0.4.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN> set dbid 1507972899executing 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 nomountstartup 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 startedTotal System Global Area 97590928 bytesFixed Size 454288 bytesVariable Size 46137344 bytesDatabase Buffers 50331648 bytesRedo Buffers 667648 bytesRMAN> restore spfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00';Starting restore at 01/MAR/05using 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/05RMAN> startup force nomountOracle instance startedTotal System Global Area 1520937712 bytesFixed Size 457456 bytesVariable Size 763363328 bytesDatabase Buffers 754974720 bytesRedo Buffers 2142208 bytesRMAN>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 /nologSQL>connect / as sysdbaConnected.

SQL> show parameter control_fileSQL> show parameter log_archive_destThe 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-1507972899-20050228-00';Starting restore at 01/MAR/05allocated 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/05RMAN> shutdownOracle instance shut downRMAN> exitRecovery 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 mountedTotal System Global Area 1520937712 bytesFixed Size 457456 bytesVariable Size 763363328 bytesDatabase Buffers 754974720 bytesRedo Buffers 2142208 bytesRMAN> 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'; # defaultRMAN>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 /nologSQL>connect / as sysdbaConnected.

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;Starting restore at 01/MAR/05using target database controlfile instead of recovery catalogallocated 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 restorechannel 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 1piece handle=E:\BACKUP\80G6E1TT_1_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_1: restored backup piece 1piece handle=E:\BACKUP\81G6E1TU_1_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_2: restored backup piece 2piece handle=E:\BACKUP\80G6E1TT_2_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_1: restored backup piece 2piece handle=E:\BACKUP\81G6E1TU_2_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_1: restored backup piece 3piece handle=E:\BACKUP\81G6E1TU_3_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_1: restore completechannel ORA_DISK_2: restored backup piece 3piece handle=E:\BACKUP\80G6E1TT_3_1.BAK tag=TAG20041130T222501 params=NULLchannel ORA_DISK_2: restore completeFinished restore at 01/MAR/05RMAN>

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/05using channel ORA_DISK_1using channel ORA_DISK_2starting media recoveryunable to find archive log archive log thread=1 sequence=1388RMAN-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 32230460RMAN>alter database open resetlogs;database openedRMAN>Note that RMAN automatically applies all available archive logs. It first applies the backed up log and then searches for subsequent logs in the archive destination. This opens the door for further recovery if the necessary logs are available. In our case, however, we have no more redo so we open the database with resetlogs. The error message above simply indicates that RMAN has searched, unsuccessfully, for subsequent logs.

That's it. The database has been recovered, from scratch, to the last available backup. Now having 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 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 AThe database is to be restored onto host BThe directory structure of host B is different to host AThe 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 any media 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 BEdit the init.ora to reflect directory structure changesConfigure SQL*Net connectivity from host to the recovery catalog and duplicated databaseSet up a password file for the duplicated databaseStartup nomount the duplicated databaseRMAN restore the controlfile(s)Mount the databaseRestore and rename the datafilesRecover and open the databaseStep:1 Backup the Target on Host AThe 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 logsbackup archivelog allformat '/oracle/backups/BFS/al_%u';# backup a copy of the controlfile that contains records for the# other backups just madebackup current controlfile tag = cf1 format '/oracle/backups/BFS/cf_%u';}Step: 2 List Datafile Locations on Host AThe datafile numbers and location on host A are required. These datafile locations will change on host BSQL> 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.dbfThe log file names should also be recorded.SQL> select group#, member from v$logfile;group# member----- ------------------------------1 /oracle/OFA_base/u01/oradata/V805X/redo01.log2 /oracle/OFA_base/u01/oradata/V805X/redo02.log3 /oracle/OFA_base/u01/oradata/V805X/redo03.logStep: 3 Make the Backups Available to Host B

Disk BackupsDuring restore, RMAN will expect the backup sets to be located in the same directory as written to during the backup.Tape BackupsThe 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_filesStep: 5 SQL*Net configuration

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 databaseIf running RMAN from host B:A Configure tnsnames.ora on host B to connect to catalog listener.ora on catalog host remains unchangedB. 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 databaseIf 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 configure listener.ora on host B to accept connections for duplicated databaseStep: 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=kernelStep: 7 Recover Duplicated Database

Startup nomount the databaseSQL> startup nomount pfile=Restore the controlfile(s)For example,run{allocate channel c1 type disk;restore controlfile;}

Mount the databaseSQL> alter database mount;Rename and restore the datafiles, and perform database recoveryRMAN can be used to change the location of the datafiles from the location on host A to the new location on host B.For example,run {allocate channel c1 type disk;allocate channel c2 type disk;allocate channel c3 type disk;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 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 RecoveryHaving 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 5RMAN> 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:ViewV$PROCESS

Identifies currently active processes.V$SESSION

Identifies currently active sessions. Use this view to determine which Oracledatabase 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 thedesired object.

run {allocate channel t1 type disk;allocate channel t2 type disk;set command id to 'rman';backupincremental level 0filesperset 5tablespace '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=rman16 22057 id=rman17 22068 id=rman,ch=t118 22070 id=rman,ch=t2Monitoring 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 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:SQL>SID SERIAL# CONTEXT SOFAR TOTALWORK % Complete8 19 1 10377 36617 28.34SQL> /SID SERIAL# CONTEXT SOFAR TOTALWORK % Complete8 19 1 21513 36617 58.75SQL> /SQL> /no rows selectedNOTE: 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 = 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 a30SELECT 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

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

Documents

RMAN Tutorial p