Wednesday, July 4, 2012

Restoring Rman backup on a different node with different backup directory structures and different database directory structures





We have a scenario here

There is difference between directory structure of host and destination machines.

Skipped 2 huge tablespaces during backup using

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE GIS_SDE_RAST;
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE GIS_SDE_RAST_INDEXES;

Created this script file

touch /u01/backup.ksh

added these lines in file

#!/bin/ksh

rman target=/ << EOF
SPOOL LOG to '/u01/dailybackup/rman.log' append;
RUN {
ALLOCATE CHANNEL ch00 TYPE DISK;
ALLOCATE CHANNEL ch01 TYPE DISK;
BACKUP
SKIP INACCESSIBLE
TAG hot_db_bk_level0
FILESPERSET 5
FORMAT '/u01/dailybackup/RMGC/df_%d_%s_%p_%t'
INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE;
sql 'alter system archive log current';
BACKUP
filesperset 20
FORMAT '/u01/dailybackup/RMGC/al_%s_%p_%t'
AS COMPRESSED BACKUPSET archivelog all delete input;
BACKUP
FORMAT '/u01/dailybackup/RMGC/cntrl_%s_%p_%t'
CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'sysdate-2′;
}
SPOOL LOG OFF;
EXIT;
EOF

give ownership to oracle user on script

chown oracle:dba /u01/backup.ksh

create a cron job

crontab -e

append these lines in crontab

30 23 * * * /usr/bin/su – oracle -c "/u01/backup.ksh"

30 23 means this job will run at 23:30 every night

First column (30) means 30 Minutes

Second Column (23) shows hour 23 (11 at night)

First * means every Month

Second * means every week

Third * means everyday of the week (if you want to run it for specific days writh in this format first day- last day
e.g. 1-5 (for first 5 days of week)

30 23 * * * /usr/bin/su – oracle /u01/backup.ksh

or

30 23 * * 1,2,3,4,5 /usr/bin/su – oracle /u01/backup.ksh

—————————————————————————————————-

Now we have to recover this backup on another machine with a totally different Directory Structure

we have 2 hard disks /u01 and /u02 with enough space to restore and recover backup files on destination server

we created directories for restore on destination server hard disks

mkdir -p /u01/RMGC/data
chown -R oracle:dba /u01/RMGC/data

mkdir -p /u02/RMGC/data
chown -R oracle:dba /u02/RMGC/data

created a database on Destination Server with same SID and similar ORACLE_BASE to Host Server

created a dummy database RMGC

Created pfile from spfile

changed location of controlfile in pfile

Started instance with pfile in nomount

While taking backup we backed up controlfile using Controlfile autobackup
after backup on host server we restored controfile from autobackup and copied it to destination server with
backupsets
or
we you can backup controlfile to trace using

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

and copy script for creation of controlfile in a text file and on destination server we can create a controlfile from this
script
——————————————————————————————————————————————–
or we can start database in nomount state and restore controlfile from autobackup;

rman target /

SET DBID 850892554

Restore the controlfile from the backup piece.
RMAN> restore controlfile from '/u01/RMGC/backup/c-3932056136-20070213-02′;

Starting restore at 13-FEB-07
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete,
elapsed time: 00:00:02
output filename=/u01/RMGC/backup/control01.ctl
Finished restore at 13-FEB-07

————————————————————————————————————

Mount the database
RMAN > alter database mount

Now catalog the backup pieces that were shipped from NODE 1

RMAN> catalog backuppiece '/u01/RMGC/backup/o1_mf_annnn_TAG20070213T002925_2x21m6ty_.bkp';
RMAN> catalog backuppiece '/u01/RMGC/backup/o1_mf_annnn_TAG20070213T002825_2x21kbds_.bkp';
RMAN> catalog backuppiece '/u01/RMGC/backup/o1_mf_nnndf_TAG20070213T002827_2x21kd12_.bkp';

This feature of cataloging backup pieces is available from ORACLE 10g versions. Prior to Oracle 10g we were not
able to catalog the backup pieces. For more information on cataloging options refer the metalink note 470463.1

Get to know the last sequence available in the archivelog backup using the following command.This will help us in
recovering the database till that archivelog.

list backup of archivelog all;
Let us assume the last sequence of last archivelog in the backup is 50.
9) Rename the Redologfiles,so that they can be created in new locations when opened the database is opened in
resetlogs
SQL> alter database rename file '/u05/RMGC/data/redo01.log' to '/u01/RMGC/data/redo01.log';

Now restore the datafiles to new locations and recover. Since we are recovering the database here till the archivelog
sequence 50 the sequence number in the SET UNTIL SEQUENCE clause should be 50 (+1)
RMAN> run
{
set until sequence 51;
set newname for datafile 1 to '/node2/database/prod/sys01.dbf';
set newname for datafile 2 to '/node2/database/prod/undotbs01.dbf';
set newname for datafile 3 to '/node2/database/prod/sysaux01.dbf';
set newname for datafile 4 to '/node2/database/prod/users01.dbf';
set newname for datafile 5 to '/node2/database/prod/1.dbf';
set newname for datafile 6 to '/node2/database/prod/sysaux02.dbf';
set newname for datafile 7 to '/node2/database/prod/undotbs02.dbf';
restore database;
switch datafile all;
recover database;
alter database open resetlogs;
}
or

if you want to skip a tablespace
$ rman target /
Recover archive logs from backup
run {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
restore archivelog sequence 1051;
restore archivelog sequence 1052;
restore archivelog sequence 1053;
restore archivelog sequence 1054;
}

we skipped two tablespaces during backup so now we don't want to recover those files
recover database skip tablespace GIS_SDE_RAST, GIS_SDE_RAST_INDEXES;
recover database skip forever tablespace GIS_SDE_RAST, GIS_SDE_RAST_INDEXES;

recover database;

alter database open resetlogs;

2 comments:

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...
This comment has been removed by a blog administrator.

Post a Comment