Case 2: All members of a log group lost

Posted On Saturday, May 21, 2011 at at 10:56 AM by Anup Kumar Srivastav

In this case an incomplete recovery is the best we can do. We will lose all transactions from the missing log and all subsequent logs. We illustrate using the same example as above. The error message indicates that members of log group 3 are missing. We don't have a copy of this file, so we know that an incomplete recovery is required. The first step is to determine how much can be recovered. In order to do this, we query the V$LOG view (when in the mount state) to find the system change number (SCN) that we can recover to (Reminder: the SCN is a monotonically increasing number that is incremented whenever a commit is issued) --The database should be in the mount state for v$log access SQL> select first_change# from v$log whnhi.ere group#=3 ; FIRST_CHANGE# ------------370255 SQL> The FIRST_CHANGE# is the first SCN stamped in the missing log. This implies that the last SCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest SCN that we can recover to. In order to do the recovery we must first restore ALL datafiles to this SCN, followed by recovery (also up to this SCN). This is an incomplete recovery, so we must open the database resetlogs after we're done. Here's a transcript of the recovery session (typed commands in bold, comments in italics, all other lines are RMAN feedback): C:\>rman target / --Restore ENTIRE database to determined SCN RMAN> restore database until scn 370254; 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!

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

Posted in Labels: Backup and Recovery | 0 comments Links to this post

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

Posted On at at 10:55 AM by Anup Kumar Srivastav If a redo log is missing, it should be restored from a multiplexed copy, if possible. Here's an example, where I attempt to startup from SQLPLUS when a redo log is missing: SQL> startup ORACLE instance started. Total System Global Area 131555128 bytes Fixed Size 454456 bytes Variable Size 88080384 bytes Database Buffers 41943040 bytes Redo Buffers 1077248 bytes Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: 'D:\ORACLE_DATA\LOGS\ORCL\REDO03A.LOG' SQL> To fix this we simply copy REDO03A.LOG from its multiplexed location on E: to the above location on D:. SQL> alter database open; Database altered. SQL> That's it - the database is open for use. Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 2: All control files lost

Posted On Friday, May 20, 2011 at at 6:11 PM by Anup Kumar Srivastav
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 RMANC:\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_C1507972899 -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; 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; --Database must be recovered because all datafiles have been restored from backup RMAN> recover database; 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. 1. 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.

2.

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 1: A multiplexed copy of the control file is available.

Posted On at at 6:10 PM by Anup Kumar Srivastav 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. Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 5: If all database lost and we have no backup of newly created data file.
Posted On at at 6:03 PM by Anup Kumar Srivastav
Step 1 Restore database and mount the database Step 2 Recover the database SQL> recover database using backup controlfile; Step 3 Check file status SQL> select file#,name,status from v$datafile; Step 4 Create datafile SQL> alter database Create datafile as size ; Step 5 Recovery the database SQL> recover automatic database using backup controlfile until cancel;

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 4: Lost datafile and No backup (When database abnormal terminated)

Posted On at at 6:02 PM by Anup Kumar Srivastav

Step 1 Startup the database with mount option SQL> startup mount Step 2 Recreate datafile SQL> alter database create datafile as size ; Step 3 Online the datafile SQL> alter database datafile online; Step 4 Now Open the database SQL> alter database open

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 3: lost data file and we have no backup (When database open)
Posted On at at 6:01 PM by Anup Kumar Srivastav
Step 1 offline the datafile SQL> alter database datafile offline; Step 2 Create datafile SQL> Create database create datafile as size ; Step 3 Recover the datafile SQL> recover datafile ; Step 4 Online the datafile SQL> alter database datafile online;

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 2: Recover from corrupted or missing data file (When database already open)
Posted On at at 5:59 PM by Anup Kumar Srivastav This scenario deal with a situation where data file has gone missing or corrupted and databases already open.

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 datafile RMAN> sql 'alter database datafile 4 offline'; --recover offlined tablespace RMAN> recover datafile 4; --online recovered tablespace RMAN> sql 'alter database datafile 4 online'; RMAN> Here we have used the SQL command, which allows us to execute arbitrary SQL from within RMAN. Posted in Labels: Backup and Recovery | 0 comments Links to this post

Case 1: Recover from corrupted or missing data file

Posted On at at 5:58 PM by Anup Kumar Srivastav
This scenario deal with a situation where data file has gone missing or corrupted at the time of open the database. 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 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 / 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; --recover restored datafile - RMAN applies all logs automatically RMAN> recover datafile 4; media recovery complete --open database for general use RMAN> alter database open; database opened trace file

RMAN>

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Recovery from Disaster

Posted On at at 5:43 PM by Anup Kumar Srivastav
Introduction:

- i.e. a situation in which your database server has been destroyed and has taken all your database files (control files, logs and data files) with it. Obviously, recovery from a disaster of this nature is dependent on what you have in terms of backups and hardware resources. We assume you have the following available after the disaster: * A server with the same disk layout as the original. * The last full hot backup on tape. With the above items at hand, it is possible to recover all data up to the last full backup. One can do better if subsequent archive logs (after the last backup) are available. In our case these aren't available, since our only archive destination was on the destroyed server ). Oracle provides methods to achieve better data protection. We will discuss some of these towards the end of the article. Now on with the task at hand. The high-level steps involved in disaster recovery are: Build replacement server. Restore backup from tape. Install database software. Create Oracle service. Restore and recover database. Step:1 Build the server You need a server to host the database, so the first step is to acquire or build the new machine. This is not strictly a DBA task, so we won't delve into details here. The main point to keep in mind is that the replacement server should, as far as possible, be identical to the old one. In particular, pay attention to the following areas: * Ideally the server should have the same number of disks as the original. The new disks should also have enough space to hold all software and data that was on the original server.

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

Step:2 Restore backup from tape The next step is to get your backup from tape on to disk. Step:3 Install Oracle Software The next step is to install Oracle software on the machine. The following points should be kept in mind when installing the software: * Install the same version of Oracle as was on the destroyed server. The version number should match right down to the patch level, so this may be a multi-step process involving installation followed by the application of one or more patch sets and patches.

*Do not create a new database at this stage. * Create a listener using the Network Configuration Assistant. Ensure that it has the same name and listening ports as the original listener. Relevant listener configuration information can be found in the backed up listener.ora file. Step:4 Create directory structure for database files After software installation is completed, create all directories required for datafiles, (online and archived) logs, control files and backups. All directory paths should match those on the original server. Don't worry if you do not know where the database files should be located. You can obtain the required information from the backup spfile and control file at a later stage. Continue reading - we'll come back to this later. Step: 5 Create Oracle service An Oracle service must be exist before a database is created. The service is created using the oradim utility, which must be run from the command line. The following commands show how to create and modify a service (comments in italics, typed commands in bold): --create a new service with auto startup C:\>oradim -new -sid ORCL -intpwd ORCL -startmode a Unfortunately oradim does not give any feedback, but you can check that the service exists via the Services administrative panel. The service has been configured to start automatically when the computer is powered up. Step: 6 Restore and recover database Now it is time to get down to the nuts and bolts of database recovery. There are several steps, so we'll list them in order: * Copy PASSWORD and TNSNAMES file from backup: The backed up password file and tnsnames.ora files should be copied from the backup directory to the proper locations. Default location for password and tnsnames files are ORACLE_HOME\database ORACLE_HOME\network\admin respectively.

* Set ORACLE_SID environment variable: ORACLE_SID should be set to the proper SID name (ORCL in our case). This can be set either in the registry (registry key: HKLM\Software\Oracle\HOME\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_C1507972899 -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 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-1507972899Starting 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-1507972899 20050228-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 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 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. 20050228-00 ';

bytes

Here is a RMAN session transcript showing the steps detailed here: RMAN> restore controlfile from 'e:\backup\CTL_SP_BAK_C-1507972899RMAN> shutdown Oracle instance shut down RMAN> exit Recovery Manager complete. C:\>rman target / Recovery Copyright connected Manager: 1995, to Release 2002, Oracle target 9.2.0.4.0 Corporation. database All (not rights Production reserved. started) 20050228-00 ';

(c)

RMAN>startup mount; Oracle instance started database mounted Total System Global Area 1520937712 Fixed Size 457456 bytes Variable Size 763363328 bytes Database Buffers 754974720 bytes Redo Buffers2142208 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'; # RMAN>

bytes

default

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;

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

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Recover Tablespace

Posted On at at 5:34 PM by Anup Kumar Srivastav To recover from a case of a dropped tablespace, the Tablespace Point In Time Recovery (TSPITR) method cannot be used. When you drop a tablespace, the controlfile will then no longer have any records of the tablespace which has been dropped. Attempts to use the RMAN RECOVER TABLESPACE command will return the RMAN error RMAN-06019 could not translate tablespace name as shown below. SQL> drop tablespace anup including contents and datafiles; Tablespace dropped. RMAN> restore tablespace anup; Starting restore at 03-AUG-09 using target database control file instead of recovery catalog allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: sid=141 devtype=SBT_TAPE channel ORA_SBT_TAPE_1: Data Protection for Oracle: version 5.5.1.0 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=140 devtype=DISK RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 08/03/2009 11:54:11 RMAN-20202: tablespace not found in the recovery catalog So to recover from a dropped tablespace, we have two options:

Do a point in time recovery of the whole database until the time the tablespace was dropped.

Create a clone of the database from a valid backup, export the required tables from the tablespace which has been dropped, recreate the tablespace and then import the tables from the clone.

The first option will require an outage of the entire database and the entire database will be rolled back in tine in order to recover the tablespace. The second option can be peformed online, but we

will need to factor in the disk space requirements to create a clone of the database from which the tablespace has been dropped.

How to find object in Tablespace SELECT * FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'tablespace_here'; Posted in Labels: Backup and Recovery | 0 comments Links to this post

Useful Query
Posted On at at 5:20 PM by Anup Kumar Srivastav Query 1 To determine which databases are currently registered in the recovery catalog: SQL> SELECT * FROM RC_DATABASE; Query 2 To determine which tablespaces are currently stored in the recovery catalog for the target database: SELECT DB_KEY, DBINC_KEY, DB_NAME, TS#, NAME, CREATION_CHANGE#, CHANGE#, CREATION_TIME, CRE_DATE FROM RC_TABLESPACE; Query 3 To determine which scripts are currently stored in the recovery catalog for the target database: SELECT * FROM RC_STORED_SCRIPT; Query 4 To list all backups of files in tablespace tbs_1 that was made since November first: RMAN> list until time 'Nov 1 1996 00:00:00' backupset of tablespace tbs_1; Query 5 To list all backups on device type 'sbt_tape': RMAN> list device type 'sbt_tape' backupset of database; Query 6

To list all database incarnations registered in the recovery catalog: RMAN> list incarnation of database; You can also use the list command to determine which copies and backups can be deleted. For example, if a full backup of the database was created on November 2, and it will not be necessary to recover the database to an earlier point-in-time, then the backup sets listed in the following report can be deleted: RMAN> list until time 'Nov 1 1996 00:00:00' backupset of database; Query 7 To report on all datafiles which need a new backup because they contain unlogged changes that were made after the last full or incremental backup. RMAN> report unrecoverable database; Query 8 To report on all datafiles which need a new backup because 3 or more incremental backups have been taken since the last full backup. RMAN> report need backup incremental 3 database; Query 9 To report on all datafiles in tablespace tbs_1 which need a new backup because the last full or incremental backup was taken more than 5 days ago. RMAN> report need backup days 5 database;

Posted in Labels: Backup and Recovery | 0 comments Links to this post

Restore and Recover database to a new host with different directory structure
Posted On at at 5:12 PM by Anup Kumar Srivastav
Restore and Recover database to a new host with different directory structure

In this case DBID of the database will be the same as of original database. Source Configuration: Host Name DB Name Database Location Backup Location Archive Location SUN1 PROD /DB/PROD /RMAN_BKP /archive

Target Configuration:
Host Name DB Name Database Location Backup Location Archive Location SUN2 PROD /INDIAN/PROD /INDIAN/RMAN_BKP /INDIAN/archive

Step 1 Take a full backup of Source Database RMAN> backup database plus archivelog; RMAN>backup spfile; - if you are using spfile , other wise take backup of pfile by using os command. Step 2 Transfer these backup pieces to target machine (/INDIAN/RMAN_BKP location) Step 3 Determine the DBID of source machine SQL> select dbid from v$database; DBID ---------142618240 Step 4 Now perform task on target machine First set ORACLE_SID, ORACLE_HOME and PATH then connect to rman Step 5 Set DBID and restore spfile or pfile. RMAN> set dbid 142618240 executing command: SET DBID RMAN> startup nomount Step 6 Restore pfile. RMAN> restore spfile to pfile '/export/home/oracle/oracle/product/10.2.0/db_1/dbs/initPROD.ora' from '/INDIAN/RMAN_BKP/c-142618240-20100927-01';

Step 7 after restoration of pfile from spfile backup . shutdown the instance. RMAN> shutdown immediate Step 8 Open parameter file and edit control_files parameter to new location (/INDIAN/PROD/) Step 7 Start the instance with pfile.

RMAN> STARTUP FORCE NOMOUNT Step 8 Restore and Mount the Control file on Target Instance RMAN> restore controlfile from '/INDIAN/RMAN_BKP/c-142618240-20100927-01'; RMAN> ALTER DATABASE MOUNT; Step 9 Catalog the all backup piece

RMAN> catalog backuppiece '/DB/RMAN_BKP/TAG20080506T150716_421c355f_.bkp'; -.. .. . RMAN> list backup Step 10 Restore the database to new location (/INDIAN/PROD) A) From SQL*Plus determine the data file and redo log file name.

SQL> SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE UNION SELECT GROUP#,MEMBER FROM V$LOGFILE B) Make a script by issuing SET NEWNAME and run. run { set newname for datafile '/DB/PROD/system01.dbf' to '/DB/ANUP/system01.dbf'; set newname for datafile '/DB/PROD/undotbs01.dbf' to '/DB/ANUP/undotbs01.dbf'; set newname for datafile '/DB/PROD/sysaux01.dbf' to '/DB/ANUP/sysaux01.dbf'; set newname for datafile '/DB/PROD/users01.dbf' to '/DB/ANUP/users01.dbf'; set newname for datafile '/DB/PROD/example01.dbf' to '/DB/ANUP/example01.dbf'; set newname for datafile '/DB/PROD/RMAN.DBF' to '/DB/ANUP/RMAN.dbf'; set newname for datafile '/DB/PROD/a.sql' to '/DB/ANUP/a.sql'; restore database; switch datafile all; } Step 11 Restore Backup archive log file to new location.

run { set archivelog destination to '/DB/archive'; restore archivelog all; } Step 12 Recover the database RMAN > recover database; Step 13 Relocate Log file location. alter database rename file '/DB/PROD/redo01.log' to '/DB/ANUP/redo01.log'; Database altered. alter database rename file '/DB/PROD/redo02.log' to '/DB/ANUP/redo02.log'; Database altered. alter database rename file '/DB/PROD/redo03.log' to '/DB/ANUP/redo03.log'; Step 14 Open the Database resetlogs option.

RMAN> alter database open resetlogs