Restoring an Oracle RMAN Backup to Different Server
Example
——–
Restore RMAN backup from CRM production server on us01ap17 to test server on test_us01ap17
The example assumes:
- the target database is on us01ap17
- the database is to be restored onto test_us01ap17
- the RMAN catalog is installed on us01ap19.
- the directory structure of test_us01ap17 is the same as us01ap17
- 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 us01ap17
- list the datafile locations on us01ap17
- make the backup available to test_us01ap17
- make a copy of the init.ora available to test_us01ap17
- if directory structure is different, edit the init.ora to reflect directory structure changes
- configure SQL*Net connectivity from host to the recovery catalog and duplicated database
- set up a password file for the duplicated database
- startup nomount the duplicated database
- RMAN restore the controlfile(s)
- mount the database
- restore and rename the datafiles
- recover and open the database
These steps are expanded further below.
1.0 Create Database on test_us01ap17
1.1 Install Oracle database using CD or downloaded files from Oracle
1.2 Ceate Oracle service
oradim -new -sid CRM -intpwd change_on_install -maxusers 20 -startmode auto
1.3 Check to see if password file was created, if not, create using the following command
orapwd file=C:\oracle\ora92\database\PWDCRM.ora password=change_on_install entries=30
1.4 Create spfile
sqlplus /nolog
connect sys/change_on_install@CRM as sysdba
shutdown immediate;
create spfile from pfile='C:\oracle\admin92\CRM\pfile\initCRM.ora';
exit;
2.0 Backup the Production database on us01ap17
———————————————-
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 (full hot backup) are written to disk.
First, create a windows batch file, fullbackup.bat
rman catalog rmanager/rmanager@rman target sys/change_on_install@CRM cmdfile=C:\Oracle\job\rman_scripts\rman_full_backup.txt log=C:\Oracle\job\rman_logs\%date:~10,4%_%date:~4,2%_%date:~7,2%_log.txt
Then, create a RMAN script file rman_full_backup.txt
run
{
resync catalog;
allocate channel ch1 device type disk format 'H:\Rman_backup\%d_%u_%s_%p';
allocate channel ch2 device type disk format 'H:\Rman_backup\%d_%u_%s_%p';
allocate channel ch3 device type disk format 'H:\Rman_backup\%d_%u_%s_%p';
#BACKUP INCREMENTAL LEVEL 0 tag = 'weekly full backup' database filesperset 1 include current controlfile;
backup incremental level 0 tag = 'full_hot_backup' ( database setsize 8192000 filesperset 1 include current controlfile );
sql 'alter system switch logfile';
sql 'alter system archive log current';
BACKUP filesperset 1 archivelog all delete input;
release channel ch1;
release channel ch2;
release channel ch3;
}
Run the batch script and you will find backup files in H:\Rman_backup
Tags: Oracle DBA
Ravi said,
January 22, 2008 @ 2:34 am
How to restore?
pepe said,
March 7, 2008 @ 5:30 am
no comment
SATISH NAWLE said,
March 30, 2009 @ 2:06 pm
When deciding on your backup strategy, Oracle recommends that you take advantage of daily incremental backups. Datafile image copies can be rolled forward with the latest incremental backups, thereby providing up-to-date datafile image copies at all times. RMAN uses the resulting image copy for media recovery just as it would use a full image copy taken at that system change number (SCN), without the overhead of performing a full image copy of the database every day. An additional advantage is that the time-to-recover is reduced because the image copy is updated with the latest block changes and fewer redo logs are required to bring the database back to the current state.
To implement daily incremental backups, a full database backup is taken on the first day, followed by an incremental backup on day two. Archived redo logs can be used to recover the database to any point in either day. For day three and onward, the previous day’s incremental backup is merged with the datafile copy and a current incremental backup is taken, allowing fast recovery to any point within the last day. Redo logs can be used to recover the database to any point during the current day.
The script to perform daily backups looks as follows (the last line, DELETE ARCHIVELOG ALL is only needed if the flash recovery area is not used to store logs):
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG ‘OSS’;
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘OSS’ DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL;
DELETE ARCHIVELOG ALL;
The standby control file will be automatically backed up at the conclusion of the backup operation because the control file auto backup is enabled.
Explanations for what each command in the script does are as follows:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL
Resynchronizes the information from all other database sites (primary and other standby databases) in the Data Guard setup that are known to recovery catalog. For RESYNC CATALOG FROM DB_UNIQUE_NAME to work, RMAN should be connected to the target using the Oracle Net service name and all databases must use the same password file.
RECOVER COPY OF DATABASE WITH TAG ‘OSS’
Rolls forward level 0 copy of the database by applying the level 1 incremental backup taken the day before. In the example script just shown, the previous day’s incremental level 1 was tagged OSS. This incremental is generated by the BACKUP DEVICE TYPE DISK … DATABASE command. On the first day this command is run there will be no roll forward because there is no incremental level 1 yet. A level 0 incremental will be created by the BACKUP DEVICE TYPE DISK … DATABASE command. Again on the second day there is no roll forward because there is only a level 0 incremental. A level 1 incremental tagged OSS will be created by the BACKUP DEVICE TYPE DISK … DATABASE command. On the third and following days, the roll forward will be performed using the level 1 incremental tagged OSS created on the previous day.
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘OSS’ DATABASE
Create a new level 1 incremental backup. On the first day this command is run, this will be a level 0 incremental. On the second and following days, this will be a level 1 incremental.
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL
Backs up archived logs to tape according to the deletion policy in place.
BACKUP BACKUPSET ALL
Backs up any backup sets created as a result of incremental backup creation.
DELETE ARCHIVELOG ALL
Deletes archived logs according to the log deletion policy set by the CONFIGURE ARCHIVELOG DELETION POLICY command. If the archived logs are in a flash recovery area, then they are automatically deleted when more open disk space is required. Therefore, you only need to use this command if you explicitly want to delete logs each day.
11.4.1.2 Commands for Weekly Tape Backups Using Disk as Cache
To back up all recovery-related files to tape, use the following command once a week:
BACKUP RECOVERY FILES;
This ensures that all current incremental, image copy, and archived log backups on disk are backed up to tape.
11.4.2 Performing Backups Directly to Tape
Oracle’s Media Management Layer (MML) API lets third-party vendors build a media manager, software that works with RMAN and the vendor’s hardware to allow backups to sequential media devices such as tape drives. A media manager handles loading, unloading, and labeling of sequential media such as tapes. You must install Oracle Secure Backup or third-party media management software to use RMAN with sequential media devices.
Take the following steps to perform backups directly to tape, by default:
Connect RMAN to the standby database (as the target database) and recovery catalog.
Execute the CONFIGURE command as follows:
CONFIGURE DEFAULT DEVICE TYPE TO SBT;
In this scenario, full backups are taken weekly, with incremental backups taken daily on the standby database.
See Also:
Oracle Database Backup and Recovery User’s Guide for more information about how to configure RMAN for use with a media manager
11.4.2.1 Commands for Daily Backups Directly to Tape
Take the following steps to perform daily backups directly to tape:
Connect RMAN to the standby database (as target database) and to the recovery manager.
Execute the following RMAN commands:
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
DELETE ARCHIVELOG ALL;
These commands resynchronize the information from all other databases in the Data Guard environment. They also create a level 1 incremental backup of the database, including all archived logs. On the first day this script is run, if no level 0 backups are found, then a level 0 backup is created.
The DELETE ARCHIVELOG ALL command is necessary only if all archived log files are not in a flash recovery area.
11.4.2.2 Commands for Weekly Backups Directly to Tape
One day a week, take the following steps to perform a weekly backup directly to tape:
Connect RMAN to the standby database (as target database) and to the recovery catalog.
Execute the following RMAN commands:
BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
DELETE ARCHIVELOG ALL;
These commands resynchronize the information from all other databases in the Data Guard environment, and create a level 0 database backup that includes all archived logs.
The DELETE ARCHIVELOG ALL command is necessary only if all archived log files are not in a flash recovery area.
11.5 Registering and Unregistering Databases in a Data Guard Environment
Only the primary database must be explicitly registered using the REGISTER DATABASE command. You do this after connecting RMAN to the recovery catalog and primary database as TARGET.
A new standby is automatically registered in the recovery catalog when you connect to a standby database or when the CONFIGURE DB_UNIQUE_NAME command is used to configure the connect identifier.
To unregister information about a specific standby database, you can use the UNREGISTER DB_UNIQUE_NAME command. When a standby database is completely removed from a Data Guard environment, the database information in the recovery catalog can also be removed after you connect to another database in the same Data Guard environment. The backups that were associated with the database that was unregistered are still usable by other databases. You can associate these backups with any other existing database by using the CHANGE BACKUP RESET DB_UNIQUE_NAME command.
When the UNREGISTER DB_UNIQUE_NAME command is used with the INCLUDING BACKUPS option, the metadata for all the backup files associated with the database being removed is also removed from the recovery catalog.
SATISH NAWLE
Samuel said,
January 25, 2011 @ 3:32 pm
Hi – thanks for the excellent info.
Our requirements are as follows, please let us know
if this is possible and guide us in this –
–Online backup + archive log + control file from DB_A.
–Copy Backup from DB_A to new server.
–Setup NEW db DB_B.
–Use the backup (from DB_A) to create new DB_B.
–And eventually on a regular basis use the archive log of DB_A
to be applied against DB_B.
Thanks in advance.
Sam.