RMAN Point-In-Time Recovery Example
There are many ways to restore a database using an RMAN backup – this example assumes you are running RMAN without a Catalog and are performing a Restore & Point-In-Time Recovery of all data back to a particular date/time in the past.
If you are running in Archive log mode and recover without specifying a date/time then RMAN will apply all Archived logs it can find, ofter recovering the database right back to the time when you started the restore operation!
If you are running in Archive log mode (and you should be), point-in time is probably the most common recovery scenario.
You will need the following information:
Database SID: ________
Database SYS password: ________
The Date and Time to restore to : ________
There are 5 steps to recover the database:
1) Restore backup files from tape
2) Mount the instance
3) Restore the datafiles
4) Recover the database
5) Reset the logs
Restore backup files from tape
If you are looking to restore the database to a time of (say 09:00) you will need the most recent RMAN backup files prior to the date (say 23:00 from the previous day) plus all the archive logs from the backup time until the restore time, in this case from 23:00 until 09:00.
If any of these files have been moved (e.g. archived to tape) restore them to the default locations on the oracle database server.
Mount the instance
C:\> Set ORACLE_SID=Live
C:\> rman TARGET SYS/Password NOCATALOG
RMAN:> shutdown immediate;
RMAN:> startup mount;
Restore and recover the datafiles
RMAN> run
{
allocate channel dev1 type disk;
set until time “to_date(‘2010-30-12:00:00:00’, ‘yyyy-dd-mm:hh24:mi:ss’)”;
restore database;
recover database; }
For a large database it can take a long time to restore each tablespace – for better performance during a restore place the RMAN backup files on a separate disk to the Oracle datafiles to reduce disk contention.
Open the database and reset logs
RMAN> alter database open resetlogs;
This will update all current datafiles and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp.
As soon as you have done a resetlogs run a full backup, this is important as should you suffer a second failure you will not be able to perform a second recovery because after resetting the logs the SCN numbers will no longer match any older backup files.
original article : http://ss64.com/ora/rman_pitr_example.html
