1 |Page

(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 perform backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database. Difference between RMAN and Traditional backup methods RMAN is Oracle's backup and recovery utility. With RMAN, backups become as easy as: BACKUP DATABASE; RMAN reduces the complexity of backup and recovery. RMAN can determine what needs to be backed up or restored. Why Should we use RMAN Ability to perform incremental backups. Ability to recover one block of a datafile. Ability to perform the backup and restore with parallelization. Ability to automatically delete archived redo logs after they are backed up. Ability to automatically backup the control file and the SPFILE. Ability to restart a failed backup without having to start from the beginning. Ability to verify the integrity of the backup. Ability to test the restore process without having to actually perform the restore. Comparison of RMAN Automated and User-Managed Procedures By using operating system commands for User-Managed Backup and Recovery , a DBA manually keeps track of all database files and backups. But RMAN performs these same tasks automatically. Understanding the RMAN Architecture An oracle RMAN comprises of RMAN EXECUTABLE This could be present and fired even through client side, TARGET DATABASE (This is the database which needs to be backed up) and RECOVERY CATALOG (Recovery catalog is optional otherwise backup details are stored in target database controlfile .) About the RMAN Repository The RMAN repository is a set of metadata that RMAN uses to store information about the target database and its backup and recovery operations. RMAN stores information about: Backup sets and pieces Image copies (including archived redo logs) Proxy copies The target database schema

2 |Page

Persistent configuration settings If you start RMAN without specifying either CATALOG or NOCATALOG on the command line, then RMAN makes no connection to a repository. If you run a command that requires the repository, and if no CONNECT CATALOG command has been issued yet, then RMAN automatically connects in the default NOCATALOG mode. After that point, the CONNECT CATALOG command is not valid in the session. Types of Database Connections You can connect to the following types of databases. Target database RMAN connects you to the target database with the SYSDBA privilege. If you do not have this privilege, then the connection fails. Recovery catalog database This database is optional: you can also use RMAN with the default NOCATALOG option. Auxiliary database You can connect to a standby database, duplicate database, or auxiliary instance (standby instance or tablespace point-in-time recovery instance Note: That a SYSDBA privilege is not required when connecting to the recovery catalog. The only requirement is that the RECOVERY_CATALOG_OWNER role be granted to the schema owner. Using Basic RMAN Commands After you have learned how to connect to a target database, you can immediately begin performing backup and recovery operations. Use the examples in this section to go through a basic backup and restore scenario using a test database. These examples assume the following: The test database is in ARCHIVELOG mode. You are running in the default NOCATALOG mode. The RMAN executable is running on the same host as the test database. Connecting to the Target Database rman TARGET / If the database is already mounted or open, then RMAN displays output similar to the following: Recovery Manager: Release 9.2.0.0.0 connected to target database: RMAN (DBID=1237603294) Reporting the Current Schema of the Target Database In this example, you generate a report describing the target datafiles. Run the report schema command as follows:

3 |Page

RMAN> REPORT SCHEMA; (RMAN displays the datafiles currently in the target database.) Backing Up the Database In this task, you back up the database to the default disk location. Because you do not specify the format parameter in this example, RMAN assigns the backup a unique filename. You can make two basic types of backups: full and incremental. Making a Full Backup Run the backup command at the RMAN prompt as follows to make a full backup of the datafiles, control file, and current server parameter file (if the instance is started with a server parameter file) to the default device type: RMAN> BACKUP DATABASE; Making an Incremental Backup Incremental backups are a convenient way to conserve storage space because they back up only database blocks that have changed. RMAN compares the current datafiles to a base backup, also called a level 0 backup, to determine which blocks to back up. RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE; Backing Up Archived Logs Typically, database administrators back up archived logs on disk to a third-party storage medium such as tape. You can also back up archived logs to disk. In either case, you can delete the input logs automatically after the backup completes.To back up all archived logs and delete the input logs (from the primary archiving destination only), run the backup command at the RMAN prompt as follows: RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT; Listing Backups and Copies To list the backup sets and image copies that you have created, run the list command as follows: RMAN> LIST BACKUP; To list image copies, run the following command: RMAN> LIST COPY; Validating the Restore of a Backup Check that you are able to restore the backups that you created without actually restoring them. Run the RESTORE ... VALIDATE command as follows:

4 |Page

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 datafile blocks that have never been used. About Incremental Backups Rman create backup only changed block since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database. How Incremental Backups Work

Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. RMAN reads the entire file every time whether or not the blocks have been used. The parent backup is the backup that RMAN uses for comparing the SCNs. If the current incremental is a differential backup at level n, then the parent is the most recent incremental of level n or less. If the current incremental is a cumulative backup at level n, then the parent is the most recent incremental of level n-1 or less. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block. Multilevel Incremental Backups RMAN can create multilevel incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, and so forth. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 backup and a full backup is that a full backup is never included in an incremental strategy.

If no level 0 backup exists when you run a level 1 or higher backup, RMAN makes a level 0 backup automatically to serve as the base. The benefit of performing multilevel incremental backups is that RMAN does not back up all blocks all of the time.
Differential Incremental Backups HostModo In a differential level n incremental backup, RMAN backs up all blocks that have changed since the most recent backup at level n or lower. For example, in a differential level 2 backups, RMAN determines which level 2 or level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. If no level 0 backup is available, RMAN makes a new base level 0 backup for this file.

5 |Page
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 following Query) Share photos with friends select incremental_level, incremental_change#, checkpoint_change#, blocks from v$backup_datafile; Result of above Query:
INC_LEVEL 0 3 3 3 2 3 3 INC_CHANGE# 0 271365 271369 271371 271365 271378 271380 CHECKPOINT_CHANGE# 271365 271369 271371 271374 271378 271380 271383 BLOCKS 59595 2 1 2 2 1 2

6 |Page

Cumulative Incremental Backups

Share photos with friends

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#

7 |Page

is an incremental backup/copy at level N or less if noncumulative or is an incremental backup/copy at level N-1 or less if cumulative belongs to an available backup set if backup

Incremental Backup Strategy

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

8 |Page

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;

9 |Page

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

10 | P a g e

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:

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

12 | P a g e

When restoring and recovering to a time when the database files that exist in the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files. If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.

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

Back up the recovery catalog metadata Upgrade the recovery catalog when necessary

Types of Files That RMAN Can Back Up The BACKUP command can back up the following types of files: Database, which includes all datafiles as well as the current control file and current server parameter file:

Tablespaces (except for locally-managed temporary tablespaces) Current datafiles Current control file Archived redo logs Current server parameter file Backup sets

RMAN does not back up the following:

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

RMAN can invoked from the command line on the database host machine like so: C:\>rman target sys/sys_password

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

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 the format for each channel. The "%U" ensures that Oracle appends a unique identifier to the backup file name. The MAXPIECESIZE attribute sets a maximum file size for each file in the backup set. Any of the above parameters can be changed using the commands displayed by the "show all" command. For example, one can turn off controlfile autobackups by issuing: RMAN> configure controlfile autobackup off; using target database controlfile instead of recovery catalog old RMAN configuration parameters: 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 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;

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 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 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\
<mailto:target=sys/password@w2k2\>

Recovery Manager: Release 9.2.0.1.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database: W2K2 (DBID=1371963417) connected to recovery catalog database

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

17 | P a g e

SQL> startup ORACLE instance started. Total System Global Area 131555128 bytes Fixed Size 454456 bytes Variable Size 88080384 bytes Database Buffers 41943040 bytes Redo Buffers 1077248 bytes Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: 'D:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG' SQL> To fix this we simply copy REDO03A.LOG from its multiplexed location on E: to the above location on D:. SQL> alter database open; Database altered. 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 access SQL> select first_change# from v$log whnhi.ere group#=3 ; FIRST_CHANGE# ------------370255 SQL> The FIRST_CHANGE# is the first SCN stamped in the missing log. This implies that the last SCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest SCN that we can recover to. In order to do the recovery we must first restore ALL datafiles to this SCN, followed by recovery (also up to this SCN). This is an incomplete recovery, so we must open the database resetlogs after we're done. Here's a transcript of the recovery session (typed commands in bold, comments in italics, all other lines are RMAN feedback):

18 | P a g e

C:\>rman target / Recovery Manager: Release 9.2.0.4.0 - Production Copyright (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/05 using channel ORA_DISK_1 using channel ORA_DISK_2 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_2: starting datafile backupset restore channel ORA_DISK_2: specifying datafile(s) to restore from backup set restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF restoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF channel ORA_DISK_2: restored backup piece 1 piece handle=E:\BACKUP\13GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL channel ORA_DISK_2: restore complete channel ORA_DISK_1: restored backup piece 1 piece handle=E:\BACKUP\14GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL channel ORA_DISK_1: restore complete Finished restore at 26/JAN/05 --Recover database RMAN> recover database until scn 370254; Starting recover at 26/JAN/05 using channel ORA_DISK_1 using channel ORA_DISK_2 starting media recovery archive log thread 1 sequence 9 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_9.ARC archive log thread 1 sequence 10 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_10.ARC archive log thread 1 sequence 11 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_11.ARC archive log thread 1 sequence 12 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_12.ARC archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_9.ARC thread=1 sequence=9 archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_10.ARC thread=1 sequence=10 media recovery complete Finished recover at 26/JAN/05

19 | P a g e

--open database with RESETLOGS (see comments below) RMAN> alter database open resetlogs; database opened RMAN> The following points should be noted: 1. The entire database must be restored to the SCN that has been determined by querying v$log. 2. All changes beyond that SCN are lost. This method of recovery should be used only if you are sure that you cannot do better. Be sure to multiplex your redo logs, and (space permitting) your archived logs! 3. The database must be opened with RESETLOGS, as a required log has not been applied. This resets the log sequence to zero, thereby rendering all prior backups worthless. Therefore, the first step after opening a database RESETLOGS is to take a fresh backup. Note that the RESETLOGS option must be used for any incomplete recovery. ================================================================= ============================================= 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

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 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 4102753520 executing command: SET DBID set DBID - get this from the name of the controlfile autobackup. For example, if autobackup name is CTL_SP_BAK_C-1507972899-20050124-00 the the DBID is 1507972899. This step will not be required if the instance is RMAN> connect target sys/change_on_install connected to target database: (not mounted) Recovery Manager: Release 9.2.0.4.0 - Production Copyright (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/05 using channel ORA_DISK_1 channel ORA_DISK_1: restoring controlfile channel ORA_DISK_1: restore complete replicating controlfile

21 | P a g e

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; Starting restore at 26/JAN/05 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to D:\ORACLE_DATA\DATAFILES\ORCL\SYSTEM01.DBF restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF channel ORA_DISK_1: restored backup piece 1 piece handle=E:\BACKUP\0DGB0I79_1_1.BAK tag=TAG20050124T115832 params=NULL channel ORA_DISK_1: restore complete channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF restoring datafile 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF channel ORA_DISK_1: restored backup piece 1 piece handle=E:\BACKUP\0CGB0I78_1_1.BAK tag=TAG20050124T115832 params=NULL channel ORA_DISK_1: restore complete Finished 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/05 using channel ORA_DISK_1 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

22 | P a g e

archive log thread 1 sequence 5 is already on disk as file D:\ORACLE_DATA\LOGS\ORCL\REDO01A.LOG archive log thread 1 sequence 6 is already on disk as file D:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG archive 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=3 archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO02A.LOG thread=1 sequence=4 archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO01A.LOG thread=1 sequence=5 archive log filename=E:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG thread=1 sequence=6 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 locallymanaged tablespaces are no longer available. You can check that this is so by querying the view V$TEMPFILE - no rows will be returned. Therefore tempfiles must be added (or recreated) before the database is made available for general use. In the case at hand, the tempfile already exists so we merely add it to the temporary tablespace. This can be done using SQLPlus or any tool of your choice: SQL> alter tablespace temp add tempfile 'D:\oracle_data\datafiles\ORCL\TEMP01.DBF';

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 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 Copyright (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 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):

24 | P a g e

--logon to RMAN C:\>rman target / Recovery Manager: Release 9.2.0.4.0 - Production 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/05 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=14 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=15 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF channel ORA_DISK_1: restored backup piece 1 piece handle=D:\BACKUP\0QGB0UEC_1_1.BAK tag=TAG20050124T152708 params=NULL channel ORA_DISK_1: restore complete Finished 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_1 using channel ORA_DISK_2 starting media recovery archive log thread 1 sequence 4 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_4.ARC archive log thread 1 sequence 5 is already on disk as file C:\ORACLE_ARCHIVE\ORCL\1_5.ARC archive log thread 1 sequence 6 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_6.ARC archive log thread 1 sequence 7 is already on disk as file E:\ORACLE_ARCHIVE\ORCL\1_7.ARC archive log filename=E:\ORACLE_ARCHIVE\ORCL\1_4.ARC thread=1 sequence=4 archive log filename=C:\ORACLE_ARCHIVE\ORCL\1_5.ARC thread=1 sequence=5 media recovery complete Finished recover at 26/JAN/05 --open database for general use RMAN> alter database open;

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 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 / Recovery Manager: Release 9.2.0.4.0 - Production Copyright (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 catalog sql statement: alter tablespace USERS offline immediate --recover offlined tablespace RMAN> recover tablespace USERS; Starting recover at 26/JAN/05 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=14 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=12 devtype=DISK starting media recovery media recovery complete Finished 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.

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 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-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 using RMAN. This is best illustrated by example: C:\>rman target / Recovery Manager: Release 9.2.0.4.0 - Production Copyright (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/05 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=19 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=20 devtype=DISK 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 starting media recovery media recovery complete Finished blockrecover at 26/JAN/05 RMAN>

27 | P a g e

Now our user should be able to query the table from her SQLPlus session. Here's her session transcript after block recovery. SQL> select count(*) from test_table; COUNT(*) ---------217001 SQL> A couple of important points regarding block recovery: 1. Block recovery can only be done using RMAN. 2. The entire database can be open while performing block recovery. 3. Check all database files for corruption. This is important - there could be other corrupted blocks. Verification of database files can be done using RMAN or the dbverify utility. To verify using RMAN simply do a complete database backup with default settings. If RMAN detects block corruption, it will exit with an error message pointing out the guilty file/block. Disaster Recovery Introduction: - i.e. a situation in which your database server has been destroyed and has taken all your database files (control files, logs and data files) with it. Obviously, recovery from a disaster of this nature is dependent on what you have in terms of backups and hardware resources. We assume you have the following available after the disaster:

A server with the same disk layout as the original. The last full hot backup on tape.

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

Build replacement server. Restore backup from tape. Install database software. Create Oracle service. Restore and recover database.

Step:1 Build the server You need a server to host the database, so the first step is to acquire or build the new machine. This is not strictly a DBA task, so we won't delve into details here. The main point

28 | P a g e

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

Ideally the server should have the same number of disks as the original. The new disks should also have enough space to hold all software and data that was on the original server. The operating system environment should be the same as the original, right up to service pack and patch level. The new server must have enough memory to cater to Oracle and operating system / other software requirements. Oracle memory structures (Shared pool, db buffer caches etc) will be sized identically to the original database instance. Use of the backup server parameter file will ensure this.

Step:2 Restore backup from tape The next step is to get your backup from tape on to disk. Step:3 Install Oracle Software The next step is to install Oracle software on the machine. The following points should be kept in mind when installing the software:

Install the same version of Oracle as was on the destroyed server. The version number should match right down to the patch level, so this may be a multi-step process involving installation followed by the application of one or more patch sets and patches. Do not create a new database at this stage. Create a listener using the Network Configuration Assistant. Ensure that it has the same name and listening ports as the original listener. Relevant listener configuration information can be found in the backed up listener.ora file.

Step:4 Create directory structure for database files After software installation is completed, create all directories required for datafiles, (online and archived) logs, control files and backups. All directory paths should match those on the original server. Don't worry if you do not know where the database files should be located. You can obtain the required information from the backup spfile and control file at a later stage. Continue reading - we'll come back to this later. Step: 5 Create Oracle service An Oracle service must be exist before a database is created. The service is created using the oradim utility, which must be run from the command line. The following commands show how to create and modify a service (comments in italics, typed commands in bold): --create a new service with auto startup C:\>oradim -new -sid ORCL -intpwd ORCL -startmode a

29 | P a g e

Unfortunately oradim does not give any feedback, but you can check that the service exists via the Services administrative panel. The service has been configured to start automatically when the computer is powered up. Step: 6 Restore and recover database Now it is time to get down to the nuts and bolts of database recovery. There are several steps, so we'll list them in order:

Copy PASSWORD and TNSNAMES file from backup: The backed up password file and tnsnames.ora files should be copied from the backup directory to the proper locations. Default location for password and tnsnames files are ORACLE_HOME\database ORACLE_HOME\network\admin respectively. Set ORACLE_SID environment variable: ORACLE_SID should be set to the proper SID name (ORCL in our case). This can be set either in the registry (registry key: HKLM\Software\Oracle\HOME<X>\ORACLE_SID) or from the system applet in the control panel. Invoke RMAN and set the DBID: We invoke rman and connect to the target database as usual. No login credentials are required since we connect from an OS account belonging to ORA_DBA. Note that RMAN accepts a connection to the database although the database is yet to be recovered. RMAN doesn't as yet "know" which database we intend to connect to. We therefore need to identify the (to be restored) database to RMAN. This is done through the database identifier (DBID). The DBID can be figured out from the name of the controlfile backup. Example: if you use the controlfile backup format , your controlfile backup name will be something like "CTL_SP_BAK_C-1507972899-20050228-00". In this case the DBID is 1507972899. Here's a transcript illustrating the process of setting the DBID:

C:\>rman Recovery Manager: Release 9.2.0.4.0 - Production Copyright (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 the nomount state. This starts up the database using a dummy parameter file. After that you can restore the spfile from the backup (which has been restored from tape ). Finally you restart the database in nomount state. Here is an example RMAN transcript for the foregoing procedure. Note the difference in SGA size and components between the two startups: RMAN> startup nomount

30 | P a g e

startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file 'C:\ORACLE\ORA92\DATABASE\INITORCL.ORA' trying to start the Oracle instance without parameter files ... Oracle instance started Total System Global Area 97590928 bytes Fixed Size 454288 bytes Variable Size 46137344 bytes Database Buffers 50331648 bytes Redo 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 catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=9 devtype=DISK channel ORA_DISK_1: autobackup found: e:\backup\CTL_SP_BAK_C-150797289920050228-00 channel ORA_DISK_1: SPFILE restore from autobackup complete Finished restore at 01/MAR/05 RMAN> startup force nomount Oracle instance started Total System Global Area 1520937712 bytes Fixed Size 457456 bytes Variable Size 763363328 bytes Database Buffers 754974720 bytes Redo 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, as this 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 | P a g e

The directories listed in the CONTROL_FILES and LOG_ARCHIVE_DEST_N parameters should be created at this stage if they haven't been created earlier. Restore control file from backup: The instance now "knows" where the control files should be restored, as this is listed in the CONTROL_FILES initialization parameter. Therefore, the next step is to restore these files from backup. Once the control files are restored, the instance should be restarted in mount mode. A restart is required because the instance must read the initialization parameter file in order to determine the control file locations. At the end of this step RMAN also has its proper configuration parameters, as these are stored in the control file. Here is a RMAN session transcript showing the steps detailed here: RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899-20050228-00'; Starting restore at 01/MAR/05 allocated channel: ORA_DISK_1 hannel ORA_DISK_1: sid=13 devtype=DISK 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_DATA\CONTROLFILE\ORCL\CONTROL02.CTL output filename=C:\ORACLE_DUP_DEST\CONTROLFILE\ORCL\CONTROL03.CTL Finished 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 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database (not started) RMAN>startup mount; Oracle instance started database mounted Total System Global Area 1520937712 bytes Fixed Size 457456 bytes Variable Size 763363328 bytes

32 | P a g e

Database Buffers 754974720 bytes Redo Buffers 2142208 bytes RMAN> show all; using target database controlfile instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'e:\backup\ctl_sp_bak_%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT 'e:\backup\%U.bak' MAXPIECESIZE 4G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\ORA92\DATABASE\SNCFORCL.ORA'; # default RMAN> At this stage we can determine the locations of data files and redo logs if we don't know where they should go. This is done from SQL Plus as follows: C:\>sqlplus /nolog SQL>connect / as sysdba 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 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/05 using target database controlfile instead of recovery catalog

33 | P a g e

allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=11 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=8 devtype=DISK 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 00003 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS01.DBF restoring datafile 00004 to D:\ORACLE_DATA\DATAFILES\ORCL\USERS02.DBF channel ORA_DISK_2: starting datafile backupset restore channel ORA_DISK_2: specifying datafile(s) to restore from backup set restoring datafile 00002 to D:\ORACLE_DATA\DATAFILES\ORCL\UNDOTBS01.DBF restoring datafile 00005 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS01.DBF restoring datafile 00006 to D:\ORACLE_DATA\DATAFILES\ORCL\TOOLS02.DBF channel ORA_DISK_2: restored backup piece 1 piece handle=E:\BACKUP\80G6E1TT_1_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 1 piece handle=E:\BACKUP\81G6E1TU_1_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_2: restored backup piece 2 piece handle=E:\BACKUP\80G6E1TT_2_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 2 piece handle=E:\BACKUP\81G6E1TU_2_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restored backup piece 3 piece handle=E:\BACKUP\81G6E1TU_3_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_1: restore complete channel ORA_DISK_2: restored backup piece 3 piece handle=E:\BACKUP\80G6E1TT_3_1.BAK tag=TAG20041130T222501 params=NULL channel ORA_DISK_2: restore complete Finished restore at 01/MAR/05 RMAN> Recover database: The final step is to recover the database. Obviously recovery is dependent on the available archived (and online) redo logs. Since we have lost our database server and have no remote archive destination, we can recover only up to the time of the backup. Further, since this is an incomplete recovery, we will have to open the database with resetlogs. Here's a sample RMAN session illustrating this: RMAN> recover database; Starting recover at 01/MAR/05 using channel ORA_DISK_1 using channel ORA_DISK_2

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:43 RMAN-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 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 A The database is to be restored onto host B The directory structure of host B is different to host A The ORACLE_SID will not change for the restored database A recovery catalog is being used The backups were carried out to disk (for illustrative purposes, and to disassociate from any media manager specific issues) The following steps are required: Backup the target on host A List the datafile locations on host A Make the backup available to host B Make a copy of the init.ora available to host B Edit the init.ora to reflect directory structure changes Configure SQL*Net connectivity from host to the recovery catalog and duplicated database

35 | P a g e

Set up a password file for the duplicated database Startup nomount the duplicated database RMAN restore the controlfile(s) Mount the database Restore and rename the datafiles Recover and open the database Step:1 Backup the Target on Host A The target database needs to be backed up using RMAN. The following is one example of RMAN doing an online database backup. In this example, the backup sets are written to disk. run { allocate channel t1 type disk; backup tag whole_database_open format '/oracle/backups/BFS/df_%u' database; # switch out of the current logfile sql 'alter system archive log current'; #backup the archived logs backup archivelog all format '/oracle/backups/BFS/al_%u'; # backup a copy of the controlfile that contains records for the # other backups just made backup current controlfile tag = cf1 format '/oracle/backups/BFS/cf_%u'; } Step: 2 List Datafile Locations on Host A The datafile numbers and location on host A are required. These datafile locations will change on host B SQL> select file#, name from v$datafile; file# name ----- -----------------------------1 /oracle/OFA_base/u01/oradata/V805X/system01.dbf 2 /oracle/OFA_base/u01/oradata/V805X/rbs01.dbf 3 /oracle/OFA_base/u01/oradata/V805X/temp01.dbf 4 /oracle/OFA_base/u01/oradata/V805X/tools01.dbf 5 /oracle/OFA_base/u01/oradata/V805X/users01.dbf 6 /oracle/OFA_base/u01/oradata/V805X/users02.dbf 7 /oracle/OFA_base/u01/oradata/V805X/rbs02.dbf 8 /oracle/OFA_base/u01/oradata/V805X/rcvcat.dbf The log file names should also be recorded.

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.log 3 /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 Traffic Counters. More information about indiandba Disk Backups During restore, RMAN will expect the backup sets to be located in the same directory as written to during the backup. Tape Backups The media management software must be configured such that host B is a media manager client, and can read the backup sets. The media management vendor should be consulted for support on this issue. Step: 4 init.ora on host B Obeus.com - Pay Per Click Advertising, Pay Per Click Affiliate Program, Free Traffic Counters. More information about indiandba The "init.ora" needs to be made available on host B. Any location specific parameters must be amended. For example, ifile, *_dump_dest, log_archive_dest*, control_files Step: 5 SQL*Net configuration Obeus.com - Pay Per Click Advertising, Pay Per Click Affiliate Program, Free Traffic Counters. More information about indiandba If running RMAN from host A: A. Connectivity to the catalog remains unchanged B. Configure tnsnames.ora on host A to connect to duplicated db on host B C. Configure listener.ora on host B to accept connections for duplicated database If running RMAN from host B: A Configure tnsnames.ora on host B to connect to catalog listener.ora on catalog host remains unchanged B. Configure tnsnames.ora on host B to connect to duplicated db on host B configure listener.ora on host B to accept connections for duplicated database

37 | P a g e

If running RMAN from host C (ie, neither host A or host B): A. Connectivity to the catalog remains unchanged B. Configure tnsnames.ora on host C to connect to duplicated db on host B configure listener.ora on host B to accept connections for duplicated database Step: 6 Setup Password File Obeus.com - Pay Per Click Advertising, Pay Per Click Affiliate Program, Free Traffic Counters. More information about indiandba In order to allow RMAN remote connections, a password file must be setup for the duplicated database. For example, orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=kernel Step: 7 Recover Duplicated Database Obeus.com - Pay Per Click Advertising, Pay Per Click Affiliate Program, Free Traffic Counters. More information about indiandba Startup nomount the database SQL> startup nomount pfile=<location of init.ora> Restore the controlfile(s) For example, run{ allocate channel c1 type disk; restore controlfile; } Mount the database SQL> alter database mount; Rename and restore the datafiles, and perform database recovery RMAN can be used to change the location of the datafiles from the location on host A to the new location on host B. For example, run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk;

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

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 copy operation is doing. You have access to several views that can assist in monitoring the progress of or obtaining information about RMAN jobs: View
V$PROCESS

Identifies currently active processes.

V$SESSION

Identifies currently active sessions. Use this view to determine which Oracle database server sessions correspond to which RMAN allocated channels.
V$SESSION_LONGOPS

Provides progress reports on long-running operations.

V$SESSION_WAIT

Lists the events or resources for which sessions are waiting. Correlating Server Sessions with Channels To identify which server sessions correspond to which RMAN channels, use the set command with the command id parameter. The command id parameter enters the specified string into the CLIENT_INFO column of the V$SESSION dynamic performance view. Join V$SESSION with V$PROCESS to correlate the server session with the channel. To correlate a process with a channel during a backup: Step:1 Start RMAN and connect to the target database . Step:2 Set the command id parameter after allocating the channels and then back up the desired object. run { allocate channel t1 type disk; allocate channel t2 type disk; set command id to 'rman'; backup incremental level 0 filesperset 5

40 | P a g e

tablespace 'SYSTEM'; # optionally, issue a host command to access the operating system prompt host; sql 'ALTER SYSTEM ARCHIVE LOG ALL'; } Step:3 Start a SQL*Plus session and then query the joined V$SESSION and V$PROCESS views while the RMAN job is executing. SELECT sid, spid, client_info FROM v$process p, v$session s WHERE p.addr = s.paddr AND client_info LIKE '%id=rman%'; SID 8 16 17 18 SPID 21973 22057 22068 22070 CLIENT_INFO id=rman id=rman id=rman,ch=t1 id=rman,ch=t2

Monitoring Job Progress Each server session performing a backup, restore, or copy reports its progress compared to the total amount of work required for that particular part of the restore. For example, if you perform a restore using two channels, and each channel has two backup sets to restore (a total of 4 sets), then each server session reports its progress through a single set. When that set is completely restored, RMAN starts reporting progress on the next set to restore. Step:1 Start RMAN and connect to the target database and, optionally, the recovery catalog database. Step:2 Start an RMAN job.: run { 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_longops WHERE opname LIKE 'RMAN%' AND opname NOT LIKE '%aggregate%' AND totalwork != 0 AND sofar <> totalwork / If you repeat the query while the backup progresses, then you see output such as the following:

41 | P a g e

SQL> SID 8 SQL> / SID 8 SQL> /

SERIAL# 19 SERIAL# 19

CONTEXT SOFAR 1 10377 CONTEXT 1 SOFAR 21513

TOTALWORK % Complete 36617 28.34 TOTALWORK % Complete 36617 58.75

SQL> / no rows selected NOTE: If you run the script at intervals of two minutes or more and the % Complete column does not increase, then RMAN is encountering a problem. SELECT sid, seconds_in_wait AS sec_wait, event FROM v$session_wait WHERE wait_time = 0 ORDER BY sid; SID SEC_WAIT 1 368383335 2 1097 3 387928 4 0 5 1408 6 386114 7 387626 8 1060 9 1060 12 1060 13 2366 14 2757 12 rows selected. EVENT pmon timer rdbms ipc message rdbms ipc message rdbms ipc message smon timer rdbms ipc message rdbms ipc message SQL*Net message from client SQL*Net message from client SQL*Net message from client SQL*Net message from client SQL*Net message from client

Note: The V$SESSION_WAIT view shows only Oracle events, not media manager events. Another Query: COLUMN EVENT FORMAT a10 COLUMN SECONDS_IN_WAIT FORMAT 999 COLUMN STATE FORMAT a20 COLUMN CLIENT_INFO FORMAT a30 SELECT p.SPID, EVENT, SECONDS_IN_WAIT AS SEC_WAIT, sw.STATE, CLIENT_INFO FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p WHERE sw.EVENT LIKE '%disk%' AND s.SID=sw.SID AND s.PADDR=p.ADDR

42 | P a g e ================================================ ================================================ ===========================