Performing post restore operation

Add the volumes exported as physical Raw Device Mapping to Oracle server for databases with volumes exported as physical RDM.

Perform a rescan of the devices on the database server.

You may use rescan-scsi-bus.sh from sg3_utils package or use appropriate iscsiadm commands, for iSCSI connections.

Post rescan operation, execute oracleasm scandisks if you use ASMLib. You may validate the ASM disks with the command oracleasm querydisk <diskname>.

From the database server, activate logical volumes and import volume groups:

# vgscan
# vgimport rh6lvm-datavg
# lvchange -ay /dev/rh6lvm-datavg/lvol0
# lvchange -ay /dev/rh6lvm-datavg/lvol1

From the database server, perform file system check, and then mount the database file systems if database files are on file systems.

# fsck -y /dev/maper/mpathc
# mount /dev/mapper/mpathc /oradata

From the database server, mount database ASM disk groups if ASM is in use. For example,

SQL>alter diskgroup <disk_group> mount;

Perform one of the following:

Extract the CONTROLFILE from metadata file path specified in RMC-O Restore user interface dialog using the following commands:
```
# cd <meta data file path> 
# tar -xvf <sid>.gz 
# gunzip controlfile.gz
```
Change the ownership of the extracted CONTROLFILE to oracle user and oinstall group.
NOTE:
For read/write snapshots in cloned status, use the control file copied from the backup server, as mentioned in the prerequisites of the Pre-Restore steps.
- If the read/write snapshot restored is a cloned database, copy the CONTROLFILE from the cloned database (backup server) manually to the database server before attempting a database recovery. For example, for database on file systems:
```
SQL> show parameter control_files;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /rcdb/redo/RCDB/controlfile/controlfile1.ctl

> scp /rcdb/redo/RCDB/controlfile/controlfile1.ctl root@production:/tmp
```
- If the read/write snapshot restored was cloned before (currently in available or mounted status), then create a clone database of this read/write snapshot, with ASCII control file and clear the Automatically Recover the Clone Database option and then copy the control file to the database server.
- If the read/write snapshot restored is in mounted or available and not cloned to a database, use the snapshot metadata provided by RMC-O.
If the read/write snapshot is restored from an Express Protect, extract the CONTROLFILE from metadata file path specified in RMC-O Restore user interface dialog using the following commands:
```
# cd <meta data file path> 
# tar -xvf <sid>_rw.gz 
# gunzip controlfile.gz
```
Change the ownership of the extracted CONTROLFILE to oracle user and oinstall group.

Connect to RMAN (rman target /) to restore the binary CONTROLFILE and run the recover database command as follows:

RMAN> startup nomount 
RMAN> restore controlfile from '<metadata file path>/controlfile'; 
RMAN> shutdown immediate 
RMAN> exit

NOTE:

Restoring CONTROLFILE is not mandatory if the new form of your database has not changed.

Connect to the SQL prompt to run the following set of commands:

SQL> startup mount 
SQL> recover database using backup controlfile until cancel; 
SQL> alter database open resetlogs; 
SQL> exit

UNTIL TIME or UNTIL SCN or UNTIL SEQUENCE clauses in the commands described in this procedure for point-in-time recovery. When prompted for archive logs, AUTO or CANCEL option can be used, based on your recovery needs. If there is any mismatch in the path of prompted archive logs, specify the paths to the actual archive logs explicitly in the prompt so that recovery succeeds. Once the recovery completes, a new form of your database is started.

NOTE:

If the read/write snapshot cloned database on the backup server is recovered, perform Post-Restore steps on the backup server.